Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-040

Text File | 1995-12-31 | 133.0 KB | 3,570 lines | [TEXT/R*ch]

Received-Date: Tue, 28 Jun 1994 15:44:39 +0200
From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-040
To: [e-mail]
Date: Tue, 28 Jun 1994 15:44:22 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Errors-To: [e-mail]
Reply-To: [e-mail]
X-Sequence: 43

C.S.M.P. Digest             Tue, 28 Jun 94       Volume 3 : Issue 40

Today's Topics:

        AppleScript Programmer's Dialect
        BlockCompare?
        GX Printing callbacks are C?
        Handling Events during AE OpenDoc Processing
        How to determine which Finder windows are open?
        Metrowerks code generation wierdness
        PPC and 64-bit video (was Re: Fast full screen scrolling: impossible?)
        Playing QuickTime movies
        Quickdraw GX - Why?
        [Q] Programming the AT&T 3210?



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users.  To search back issues
with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use
http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html.


-------------------------------------------------------

>From [e-mail] (Joseph Hall)
Subject: AppleScript Programmer's Dialect
Date: Fri, 3 Jun 1994 22:28:40 GMT
Organization: Motorola Inc., Satellite Communications

Is the programmer's dialect real, or just a figment of the Language Guide's
imagination?

--
Joseph Nathan Hall | Joseph's Law of Interface Design: Never give your users
Software Architect | a choice between the easy way and the right way.
Gorca Systems Inc. |                 [e-mail] (home)
(on assignment)    | [phone] (work)  [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Mel Walker)
Date: Mon, 6 Jun 1994 16:02:46 GMT
Organization: Committee to Elect Dan Quayle Lord of the Cosmos

Joseph Hall ([e-mail]) wrote:
: Is the programmer's dialect real, or just a figment of the Language Guide's
: imagination?

Also, are instructions for making dialects published anywhere? Probably
not, right?
--
Mel Walker                                     [e-mail]
"That is one of the unwritten rules of government bureaucracy:
Doing something idiotic is not advisable; getting caught doing
something idiotic is a disaster." - Mike Royko

+++++++++++++++++++++++++++

>From [e-mail] (Mark Minshull)
Date: Mon, 6 Jun 1994 17:55:42 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Joseph
Hall) wrote:

> Is the programmer's dialect real, or just a figment of the Language Guide's
> imagination?
>
At this point, it's a still-born project...

  Mark
--
Mark Minshull                       :       [e-mail]
OpenDoc Engineering Manager         :
Apple Computer, Inc.                :       Apple usually doesn't care
1 Infinite Loop, MS 303-3A          :       what I say... When they do
Cupertino, CA  95014                :       my opinions are my own.

+++++++++++++++++++++++++++

>From [e-mail] (Mark Minshull)
Date: Mon, 6 Jun 1994 17:58:00 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Mel Walker)
wrote:

>
> Also, are instructions for making dialects published anywhere? Probably
> not, right?

Right.  The interface is private...

--
Mark Minshull                       :       [e-mail]
OpenDoc Engineering Manager         :
Apple Computer, Inc.                :       Apple usually doesn't care
1 Infinite Loop, MS 303-3A          :       what I say... When they do
Cupertino, CA  95014                :       my opinions are my own.

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Mon, 6 Jun 1994 20:05:00 GMT
Organization: Apple Computer

Joseph Hall, [e-mail] writes:
> Is the programmer's dialect real, or just a figment of the Language Guide's
> imagination?

Sue Dumont of the AppleScript team wrote one, but there aren't any plans I
know of to ship it. It's pretty cool, but it needs some work before it's
ready for prime time.

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Mon, 6 Jun 1994 22:52:01 GMT
Organization: Apple Computer

Mel Walker, [e-mail] writes:
> Also, are instructions for making dialects published anywhere? Probably
> not, right?

Making dialects (a) is pretty complicated and (b) requires more access to the
internals of the AppleScript engine than Apple wants to give 3rd parties. A
large part of it involves writing yacc syntax descriptions whose tables then
get dumped into the dialect file.

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

+++++++++++++++++++++++++++

>From [e-mail] (Mel Walker)
Date: Tue, 7 Jun 1994 17:07:02 GMT
Organization: Committee to Elect Dan Quayle Lord of the Cosmos

Jens Alfke ([e-mail]) wrote:
: Mel Walker, [e-mail] writes:
: > Also, are instructions for making dialects published anywhere? Probably
: > not, right?

: Making dialects (a) is pretty complicated and (b) requires more access to the
: internals of the AppleScript engine than Apple wants to give 3rd parties. A
: large part of it involves writing yacc syntax descriptions whose tables then
: get dumped into the dialect file.

I assume that I could write a scripting component that opened up the
AppleScript component, and translate my "dialect" into AppleScript that
way. Is there anything that would prevent that?

--
Mel Walker                                     [e-mail]
"That is one of the unwritten rules of government bureaucracy:
Doing something idiotic is not advisable; getting caught doing
something idiotic is a disaster." - Mike Royko

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Tue, 7 Jun 1994 22:04:44 GMT
Organization: Apple Computer

Mel Walker, [e-mail] writes:
> I assume that I could write a scripting component that opened up the
> AppleScript component, and translate my "dialect" into AppleScript that
> way. Is there anything that would prevent that?

That'd work; your component would just forward all of its calls to
AppleScript. The compile and getsource calls would have to do some
transformation on the source text to change it from/to your syntax to/from
AppleScript. (Don't forget the getsource call or people won't be able to
re-edit compiled scripts!) And also don't forget to fix up the source
positions in the error descriptor when the client wants to know the source
range of the error.

 Of course this would only work with one dialect of AppleScript.

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

+++++++++++++++++++++++++++

>From [e-mail] (Jon Wdtte)
Date: 9 Jun 1994 08:55:24 GMT
Organization: The Royal Institute of Technology

In <[e-mail]> [e-mail] (Mark Minshull) writes:

>In article <[e-mail]>, [e-mail] (Mel Walker)
>wrote:

>> Also, are instructions for making dialects published anywhere? Probably
>> not, right?

>Right.  The interface is private...

How come there's a tickle dialect of the OSA then?

Cheers,


                    / h+
--
 -- Jon W{tte, [e-mail], Mac Software Engineer Deluxe --

 -- I don't fear death, it's dying that scares me.

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Thu, 9 Jun 1994 18:29:45 GMT
Organization: Apple Computer

Jon W!tte, [e-mail] writes:
> How come there's a tickle dialect of the OSA then?

That's not an AppleScript dialect, it's an entirely separate OSA component,
like Frontier or QuicKeyScript. The difference is that a dialect is just a
plug-in parser (and unparser) for the AppleScript compiler, whereas a
scripting component is entirely independent of AppleScript. To write a new
scripting component you just have to follow the OSA API, whereas dialects are
pretty tightly coupled to AppleScript's internal parsing engine and build
system.

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

+++++++++++++++++++++++++++

>From [e-mail] (Mel Walker)
Date: Thu, 9 Jun 1994 21:57:58 GMT
Organization: Committee to Elect Dan Quayle Lord of the Cosmos

Jon Wdtte ([e-mail]) wrote:
: In <[e-mail]> [e-mail] (Mark Minshull) writes:

: >In article <[e-mail]>, [e-mail] (Mel Walker)
: >wrote:

: >> Also, are instructions for making dialects published anywhere? Probably
: >> not, right?

: >Right.  The interface is private...

: How come there's a tickle dialect of the OSA then?

There's not. AppleScript is one OSA _language_ with several _dialects_.

Quickeys, tickle, etc. store their internal scripts in a different form
than AppleScript does, so their scripts are not compatible. If you
program AppleScript in the English dialect, and select the French
dialect, the script will change to reflect that without changing
the underlying tokenized form.

Did I get that right, O Great Gurus from Apple?
--
Mel Walker                                     [e-mail]
"That is one of the unwritten rules of government bureaucracy:
Doing something idiotic is not advisable; getting caught doing
something idiotic is a disaster." - Mike Royko

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Fri, 10 Jun 1994 10:03:12 +0800
Organization: Department of Computer Science, The University of Western Australia

In article <2t6lds$[e-mail]>, [e-mail] (Jon Wdtte)
wrote:

>In <[e-mail]>
[e-mail] (Mark Minshull) writes:
>
>>In article <[e-mail]>, [e-mail] (Mel Walker)
>>wrote:
>
>>> Also, are instructions for making dialects published anywhere? Probably
>>> not, right?
>
>>Right.  The interface is private...
>
>How come there's a tickle dialect of the OSA then?

You're confusing your dialects with your OSA scripting components.  A
dialect is a different natural language (or syntax in the case of the
Programmer's Dialect) for *AppleScript*.  An OSA scripting component lets
you implement an entirely different programming language within the
framework of the OSA.

So AppleScript currently has 3 dialects (English, French, Japanese) which
all compile to the same language (AppleScript).  There are also buckets of
other OSA scripting components (QuickKeys, TCL, etc).
--
Quinn "The Eskimo!"      <[e-mail]>     "Support HAVOC!"
Department of Computer Science, The University of Western Australia
  The cute thing is that you can compile a script in one dialect and
  then decompile it in another.  If only it translated the identifiers.
  Such a shame the Translation Manager doesn't live up to its name (:

+++++++++++++++++++++++++++

>From [e-mail] (msouth on BIX)
Date: 14 Jun 94 05:31:10 GMT
Organization: Delphi Internet Services Corporation

[e-mail] (Mel Walker) writes:

>Quickeys, tickle, etc. store their internal scripts in a different form
>than AppleScript does, so their scripts are not compatible. If you
>program AppleScript in the English dialect, and select the French
>dialect, the script will change to reflect that without changing
>the underlying tokenized form.

You know, this is a _perfect_ example of how the Mac is head
and shoulders above anything else. But do you think that anyone
other than a already-dedicated Mac programmer knows about it?
Why on earth doesn't Apple _advertise_ some of this stuff?

+++++++++++++++++++++++++++

>From [e-mail]
Date: 14 Jun 94 12:45:21 MST
Organization: (none)

In article <[e-mail]>, [e-mail] (msouth on BIX) writes:
> [e-mail] (Mel Walker) writes:
>
>>Quickeys, tickle, etc. store their internal scripts in a different form
>>than AppleScript does, so their scripts are not compatible. If you
>>program AppleScript in the English dialect, and select the French
>>dialect, the script will change to reflect that without changing
>>the underlying tokenized form.
>
> You know, this is a _perfect_ example of how the Mac is head
> and shoulders above anything else. But do you think that anyone
> other than a already-dedicated Mac programmer knows about it?
> Why on earth doesn't Apple _advertise_ some of this stuff?

I tell DOS-bigots all the time and their response is: "whoopee! Who would ever
need to do something like that...

Oh well.


Lawson

---------------------------

>From [e-mail] (Spencer Low)
Subject: BlockCompare?
Date: 12 Jun 1994 14:44:31 -0700
Organization: LowTek Creations

I'm looking for some sample code (preferably in C) that will compare to
blocks of memory. In other words:

   Boolean BlockCompare(Ptr block1, Ptr block2, Size byteCount);

The C libraries that come with THINK C include memcmp, but it's
hand-coded in 68K assembly. I'd prefer something less platform dependent,
yet still quick.

Thanks,
Spencer (btw, I didn't see anything like this at the alt.sources.mac
archives)
--
  Spencer Low       | MaxRAM: Compatible with RD 1.0.1 and 1.0.2,
  LowTek Creations  |         but not yet with RD 1.0.3A.
  [e-mail]  | ftp://crl.com/users/ro/spencerl/

+++++++++++++++++++++++++++

>From [e-mail] (Anton Rang)
Date: 13 Jun 1994 01:32:50 GMT
Organization: Minnesota Angsters

In article <2tfvjv$[e-mail]> [e-mail] (Spencer Low) writes:
>I'm looking for some sample code (preferably in C) that will compare to
>blocks of memory. In other words:
>
>   Boolean BlockCompare(Ptr block1, Ptr block2, Size byteCount);
>
>The C libraries that come with THINK C include memcmp, but it's
>hand-coded in 68K assembly. I'd prefer something less platform dependent,
>yet still quick.

  Just to see if they're equal?

  You probably can't beat a loop like this, in C, without adding
various platform dependent tricks:

    while (byteCount--)
      if (*block1++ != *block2++)
        return (false);

    return (true);

If you're using 68K assembly, you can do very well using 'cmpm' and a
'dbra' variant, if your loop counts will fit in a two-byte variable.
Something along the lines of

    @0:    cmpm.l    (a0)+, (a1)+        ; or .b if you really need byte-by-byte
    dbne    @0            ; branch until not-equal
    seq    d0            ; set d0 to be non-zero if they match
    rts                ; return

Using memcmp() is your best bet for a platform-independent quick way,
since it's part of the ANSI standard and probably coded in assembly.
--
Anton Rang ([e-mail])

+++++++++++++++++++++++++++

>From [e-mail] (Bretton Wade)
Date: 13 Jun 1994 04:14:26 GMT
Organization: Program of Computer Graphics -- Cornell University

probably your best bet if you want to do it in a high level language is to
make a nice unrolled loop. you'd have to know in general that the size of the
block you want to compare is divisible by some factor (say 16)..

Boolean    compare (long *a, long *b, long blocksize)
{
    for (short i = 0; i < blocksize; i += 16)
    {
        if (*a++ != *b++) return FALSE;
        if (*a++ != *b++) return FALSE;
        if (*a++ != *b++) return FALSE;
        if (*a++ != *b++) return FALSE;
    }
    return TRUE;
}

the more compares you can do inside the loop, the better off you'll be (up to a
point). You may also need a little code that will check any leftover that you
couldn't cover with the big blocks. say you've got 64001 bytes to compare. You
would check the first 64000 with a big block checker, then test the last byte
separately.

THINK's memcmp function checks one byte at a time. you should be able to blast
that with C code quite easily...
--
_______________________________________________________________________________

   Bretton Wade ([e-mail])

   Program of Computer Graphics
   580 Engineering and Theory Center
   Cornell University
   Ithaca, NY 14853
   Voice: [phone]
   Fax:   [phone]
_______________________________________________________________________________

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Mon, 13 Jun 1994 20:11:26 GMT
Organization: Apple Computer

Spencer Low, [e-mail] writes:
> The C libraries that come with THINK C include memcmp, but it's
> hand-coded in 68K assembly. I'd prefer something less platform dependent,
> yet still quick.

If you want portability, use memcmp. You can't get much more portable than
the ANSI library -- any C implementation you use, anywhere, is guaranteed to
have one.

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

---------------------------

>From Jens Alfke <[e-mail]>
Subject: GX Printing callbacks are C?
Date: Thu, 9 Jun 1994 18:02:49 GMT
Organization: Apple Computer

Looks like the entire GX team is on vacation this week, unless they're just
refusing to return my calls, so I'll have to make like a layperson and ask
the net...  ;-)

I'm adding GX print manager support to a QD-based app of mine (well, Sticky
Memos, but this feature won't be in 1.0.) I'm following the prerelease
'develop' article.

I note that the various callbacks you need to install (event filtering and
shape spooling) are not declared as 'pascal' functions. This strikes me as
odd since (as has been discussed recently) there are no standard C calling
conventions on the Mac and the three major C compilers all do things
differently.

Is this going to be a problem for me? My app's written in CodeWarrior. The
major thing I remember is that MPW passes all parameters of any size as
longs, so I may have to make sure that any short or Boolean params are
declared in my callback functions as longs. Is there anything else I need to
do (besides declaring the functions as extern "C", of course)?

And what do Pascal users do about this? I've heard that MPW Pascal can use C
calling conventions, but what about THINK Pascal? At the risk of not sounding
like a team player, I have to say that this C-callbacks thing in GX may not
have been the most well thought out idea in the world.

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Fri, 10 Jun 1994 10:30:53 +0800
Organization: Department of Computer Science, The University of Western Australia

In article <[e-mail]>, Jens Alfke
<[e-mail]> wrote:

>I note that the various callbacks you need to install (event filtering and
>shape spooling) are not declared as 'pascal' functions. This strikes me as
>odd since (as has been discussed recently) there are no standard C calling
>conventions on the Mac and the three major C compilers all do things
>differently.
>
>Is this going to be a problem for me? My app's written in CodeWarrior. The
>major thing I remember is that MPW passes all parameters of any size as
>longs, so I may have to make sure that any short or Boolean params are
>declared in my callback functions as longs. Is there anything else I need to
>do (besides declaring the functions as extern "C", of course)?

The situation is like this...

MPW and CodeWarrior Pascal can both call external functions written in C.
You simply declare the function header and take a "C;" after it, with an
optional "EXTERNAL;" after that.  Think cannot do this and it sucks big
time.

*None* of the Pascal compilers can compile a function written in Pascal
that uses C calling conventions.  So if you want to do C calling
convention callbacks you are basically stuffed.

My workaround to this is to write the necessary glue in C, where all the
compilers support all the calling conventions.  Peter Lewis (who uses
Think Pascal exclusively) works around this by declaring the functions
with no parameters, getting the value of the A6 register and then walking
up the stack manually.  It's yucky, it's non-portable, it works.

btw It's not just a question of making the parameters match in size.  The
problem is that C requires the callee to remove the parameters and Pascal
(normally) has the caller removing them.  So you have to declare the
function with *no* parameters to avoid big dramas with the stack.  Oh yeah
and returning stuff in D0 is kinda hard too.

I haven't actually looked through GX yet but if it's full of C callbacks
then I'm gonna be *extremely* depressed.

>And what do Pascal users do about this? I've heard that MPW Pascal can use C
>calling conventions, but what about THINK Pascal? At the risk of not sounding
>like a team player, I have to say that this C-callbacks thing in GX may not
>have been the most well thought out idea in the world.

Well we get bitter and twisted and wear "C, Stop It or You'll Go Blind!"
T-shirts around WWDC and harrass the guys doing the interfaces about using
a decent IDL so that we can generate Pascal interfaces (and, if necessary,
glue code) automatically.  The depressing thing is that (I think) we've
got a lot of sympathy but there's this little thing called "economic
imperative" that ensures that no one does anything to help.  *sigh*

One nice thing is that the PPC has One True Calling Convention (tm).
Hopefully this will improve matters.

Share and Enjoy.
--
Quinn "The Eskimo!"      <[e-mail]>     "Support HAVOC!"
Department of Computer Science, The University of Western Australia
  Maintain the Rage!!!

+++++++++++++++++++++++++++

>From [e-mail] (Pete Resnick)
Date: Thu, 09 Jun 1994 22:09:47 -0500
Organization: University of Illinois at Urbana-Champaign

In article <[e-mail]>,
[e-mail] (Quinn "The Eskimo!") wrote:

>btw It's not just a question of making the parameters match in size.  The
>problem is that C requires the callee to remove the parameters and Pascal
>(normally) has the caller removing them.

You got that backwards. The caller resets the stack in *C* and the callee
removes them in Pascal.

pr
--
Pete Resnick        (...so what is a mojo, and why would one be rising?)
Doctoral Student - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Fri, 10 Jun 1994 21:11:41 GMT
Organization: Apple Computer

In article <[e-mail]> Quinn,
[e-mail] writes:
> MPW and CodeWarrior Pascal can both call external functions written in C.

Pascal access is certainly an issue, but not the one that immediately
concerns me since I'm writing in C++. The problem is that GX presumably calls
my callbacks with MPW calling conventions*, whereas my functions are
implemented using CodeWarrior conventions. As has been discussed in the
context of linking with .o files, the two are different and you have to be
careful about what size the params are and what register the results get
returned in.

*Actually that's not even certain since I know that at least the graphics
engine of GX was developed in THINK C. I'm guessing that for the real builds
they compiled it with MPW, given the MPW-bigotry inside Apple... ;-)

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

+++++++++++++++++++++++++++

>From [e-mail] (Marshall Clow)
Date: 10 Jun 1994 21:48:39 -0700
Organization: California State University San Marcos

Jens Alfke ([e-mail]) wrote:
>In article <[e-mail]> Quinn,
>[e-mail] writes:
>> MPW and CodeWarrior Pascal can both call external functions written in C.

>Pascal access is certainly an issue, but not the one that immediately
>concerns me since I'm writing in C++. The problem is that GX presumably calls
>my callbacks with MPW calling conventions*, whereas my functions are
>implemented using CodeWarrior conventions. As has been discussed in the
>context of linking with .o files, the two are different and you have to be
>careful about what size the params are and what register the results get
>returned in.

    Starting with GM (dontcha just love it? ;-) the GX header files
contain a "#ifdef applec" section that defines the calls for the MPW C
compiler, and an '#else' section that works for MetroWerks and Think C.
The files affected are PrintingDrivers.h and PrintingMessages.h (I think).

    Several of the GX libraries contain "non pascal" routines with
short parameters, but since source to the libs is provided, these interfaces
were not changed.

Marshall Clow
Amateur GX Weenie
Aladdin Systems
mclow@san_marcos.csusm.edu
[ Apparently the first person to write a GX printer driver in Think C.]


+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 13 Jun 94 18:03:18 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Quinn "The Eskimo!") writes:
> In article <[e-mail]>, Jens Alfke
> <[e-mail]> wrote:
>
>>I note that the various callbacks you need to install (event filtering and
>>shape spooling) are not declared as 'pascal' functions.
>>
>>Is this going to be a problem for me? My app's written in CodeWarrior. The
>>major thing I remember is that MPW passes all parameters of any size as
>>longs, so I may have to make sure that any short or Boolean params are
>>declared in my callback functions as longs. Is there anything else I need to
>>do (besides declaring the functions as extern "C", of course)?
>
> *None* of the Pascal compilers can compile a function written in Pascal
> that uses C calling conventions.  So if you want to do C calling
> convention callbacks you are basically stuffed.
>
> My workaround to this is to write the necessary glue in C, where all the
> compilers support all the calling conventions.  Peter Lewis (who uses
> Think Pascal exclusively) works around this by declaring the functions
> with no parameters, getting the value of the A6 register and then walking
> up the stack manually.  It's yucky, it's non-portable, it works.

My workaround is a generic piece of assembly-language glue which looks
something like this:

    clr.w    -(sp)    ; room for Pascal function result
    pea    6(sp)    ; pointer to C-format argument list
    jsr    PascalRoutine ; call my Pascal-conforming routine
    move.w    (sp)+, d0 ; return Pascal result to C
    rts

The Pascal-conforming routine (in Modula-2, in my case) is declared like this:

    PROCEDURE MyHandler
      (
        VAR Args : ArgsForThisRoutine
      ) : OSErr;

where "ArgsForThisRoutine" is a record type that mimics the format of the
C argument list. So I refer to the arguments as "Args.whatever". Not too
painful at all.

One common case is printing extensions and drivers. This introduces its own
fiddly bits, in that the offsets in the 'over' resources must match the entry
points in your 'pext' code resources. To solve all this, I wrote a custom MPW
tool which takes a file of entry point definitions, and generates .o files for
the segment headers (including the C-to-Pascal glue, above), and the 'over'
resources, all in one fell swoop, so you never have to worry about keeping
them consistent again. Nifty, huh?

Lawrence "Just call me the 'Speedbump, the Roadkill Hedgehog' of the
Information Superhighway" D'Oliveiro

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Tue, 14 Jun 1994 09:44:37 +0800
Organization: Department of Computer Science, The University of Western Australia

In article <[e-mail]>, [e-mail]
(Lawrence D'Oliveiro, Waikato University) wrote:

>My workaround is a generic piece of assembly-language glue which looks
>something like this:
>
>[...]

Neat hack!

Unfortunately the problem still stands, no matter how neat a hack you use
to work around it ):

>Lawrence "Just call me the 'Speedbump, the Roadkill Hedgehog' of the
>Information Superhighway" D'Oliveiro

*laugh*
--
Quinn "The Eskimo!"      <[e-mail]>     "Support HAVOC!"
Department of Computer Science, The University of Western Australia

---------------------------

>From [e-mail]
Subject: Handling Events during AE OpenDoc Processing
Date: 13 Jun 94 00:52:37 PST
Organization: California State Polytechnic University, Pomona

What's the best way to handle event processing during an AppleEvent
OpenDocument event?

In my application I step thru the docList retrieved from the AppleEvent and
call my OpenDocument routine on each document as it is pulled out of the list.
I'd like to put up a MovableModal or Modeless dialog to show progress and also
allow the user to switch to other applications and even drop more documents on
my application while it is running (I'm using a suspend/resume appleevent
routine similar to the ones used in DragonSmith). Should I setup another event
loop that I call during the Opening of the documents? All my application does
is rename files based on settings the user specifies beforhand so the actual
operations on each file are small but, I'd like get a good strategy for
handling events when the processing time for each document increases.

Any comments are appreciated.


+++++++++++++++++++++++++++

>From [e-mail] (Dana Cartwright 3rd)
Date: Mon, 13 Jun 1994 11:45:06 GMT
Organization: Syracuse University, Syracuse, New York

[e-mail] wrote:
: ..... I'd like get a good strategy for
: handling events when the processing time for each document increases.

A strategy I use (and others in this group have mentioned similar
strategies) is to divide my app into two parts, call them "hot" and
"cool".  The "hot" part is responsible for being highly responsive to
user requests (keystrokes and menu actions).  The "cool" part handles
things which take a longer time.

In the "hot" sections, anything which would take a long time to execute
is avoided...instead, a request is enqueued for the "cool" code to do
the long-running work (the details of how this is done probably depend
on your app, see my strategy below).

When I call WNE and find I have no events queued up for me, I then
dispatch the "cool" code.  It looks in its work-to-be-done queue and
starts grinding away.  Since these are long-running tasks, there's a lot
of the style of coding where tasks are interrupted with calls to WNE.

When the "cool" code is running, it will happen (frequently) that the
user does something which causes the "hot" code to run.  So the "cool"
and the "hot" code have to understand that they may run interleaved.

Note: this description is basically a description of cooperative multi-
tasking, but carried out within one app rather than among apps.  The
point is that it works beautifully.....my apps are highly responsive
to mouse clicks, and you can "stack" a whole series of them with the
app giving very quick visual feedback...also, you can issue a bunch of
mouse clicks and then switch my app into the background.....all the
"cool" code expects that it may run while the app is in the background.

Now, for my enqueue strategy: it's extremely simple!  I just have a
global 32-bit word in which each bit corresponds to some "cool" task.
When the "hot" code sees that it needs to ask the "cool" routines to
take on some work, it just flips on whichever of the 32 bits corresponds
to that particular task.  In the "cool" code, there are up to 32
tasks which can be dispatched, keyed off the 32 bits of the dispatch
word.  By the way, since I dispatch starting with the left-most bit,
I also achieve a strict prioritization: higher priority "cool" tasks
are given bits near the high-order end of the 32-bit word.  Since
enqueue/dequeue of tasks is no harder than flipping a bit, I've not
got much overhead.

Anyway, I've used this strategy in several commercial apps, and users
have commented on how responsive the software seems to be....so I
claim some success!


+++++++++++++++++++++++++++

>From [e-mail] (Vincent Partington)
Date: 14 Jun 1994 10:30:17 +0200
Organization: FWI, University of Amsterdam

[e-mail] writes:

>What's the best way to handle event processing during an AppleEvent
>OpenDocument event?

The other replier mentioned partitioning his application into a "hot" and
"cold" part. I do something similar but the implementation is
different. I divide my programs into an interface part and a grunt-work part.

The interface part handles the interface stuff and has to be quick in giving
time to other apps and is centered around the event loop. When the interface
part wants the grunt-work part to do something it sends an Apple Event with
all necessary information to itself.

The grunt-work part gets this information from the AppleEvent and starts
processing but calls the "Yield" function at regular intervals. The Yield
functions is the interface part: it does a WaitNextEvent and handles events
until a null event comes up. Then the grunt-work part can continue.

The advantage of this recursion is that I have one event-loop and that the
grunt-work part can be structured like you would on a machine with preemptive
multitasking and no event-loop. You only have to call Yield once in a while,
you don't have to split up your work and do it in little chunks getting the
necessary status info from flag words and such (was I doing X or Y?).

But because of the recursion care should be taken not to get into infinite
recursion. I do this by calling the "Activate" method of my Application-class
when ever the grunt-work part start to do stuff that could take long: that
method disables the menubar and sets the event mask to exclude High Level
events. It also sets a flag so the Yield function knows to give a sleep time
of 0 ticks to WaitNextEvent. At the end of the grunt-work function (the Apple
Event handler) the "Deactivate" method is called and the application returns
to idle state.

Another advantage is that all communication goes to the grunt-work part
through Apple Events: because of this my applications are recordable and
scriptable.

I have developed no commercial applications with this, but I'm developing a
C++ DropBox class library using this approach. The idea is to make it easy
to implement an algorithm for file conversion (like Unix "filters") without
having to muck about with event loops.
This class library should see the public domain when CodeWarrior supports
exception handling and templates, so I can test my exception handling code.

Vincent.
--
My opinions are not my own. I copy them    | Internet : [e-mail]
from books, television, video, the net,    |            [e-mail]
my friends, my parents, my teachers and    | FidoNet  : 2:281/202.15
and numerous other contributors.           | NeST     : 90:500/202.15

---------------------------

>From [e-mail] (Alex Metcalf)
Subject: How to determine which Finder windows are open?
Date: Fri, 10 Jun 1994 23:17:19 GMT
Organization: Best Before Yesterday


Up until a few weeks ago I thought it was impossible to read information
such as which Finder windows are open, the positions of icons in that
window (I know that's in the DB, but I don't know how to check for the open
window), etc.

However, Popup Folder lets you click on a finder folder and see some stuff
about its hierarchy. So there MUST be a way! Also, that screen saver
software that has stuff interacting with your finder windows.

I've posted once already with no reply, and this information would be
really useful for me. Can anyone help me by telling me how my app can find
out ANY of these:

o   The open windows in the Finder
o   The names / folder paths of open windows in the Finder
o   The names and locations of folders in an open window in the Finder

Thanks!


Alex

--
Alex Metcalf, Best Before Yesterday
Mac programmer in C, C++, HyperTalk, assembler
Juggler, 3-ball tricks

Internet:          [e-mail]
Fax (UK):          (0570) 45636
Fax (US / Canada): 011 44 570 45636

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Mon, 13 Jun 1994 05:37:31 GMT
Organization: cellular

[e-mail] (Alex Metcalf) writes:

>Up until a few weeks ago I thought it was impossible to read
>information such as which Finder windows are open, the positions of
>icons in that window (I know that's in the DB, but I don't know how
>to check for the open window), etc. However, Popup Folder lets you
>click on a finder folder and see some stuff about its hierarchy. So
>there MUST be a way! Also, that screen saver software that has stuff
>interacting with your finder windows.

The question is not whether it can be done or how it can be done. Those
are comparatively easy questions, and I will take a swipe at answering
them below. The really interesting question, however, is this: do you
really want to?

Finder is an application. Like many apps, it stores data in the 'refCon'
field of its window records. That data, I believe, is a handle, but
perhaps a pointer, to a C++ object which contains handles or pointers
to other C++ objects, etc. etc. Using MacsBug, you can reverse engineer
these *absitively posolutely private* data structures to determine the
information you want.

Of course, this assumes you somehow have access to Finder's window list.
You'll probably have to write an INIT resource to do this.

This is the first part of the question: do you really want to do all the
work involved in this reverse engineering? It's non-trivial, especially
if your MacsBug skills are not polished.

The second part of the question is more of the same. Assuming you want
to put in this kind of work, are you willing to put in this kind of work
for System 7, System 7.1, System 7 Pro, and System 7.5? How about System
6 and for each version of the System before? And each version of the
System after 7.5? Because the information is different in all of these
cases.

I'm not trying to be a wet blanket, but I do feel like I ought to try to
discourage you for your own good. You can do it; I've done it. But you
had better be sure it's worth the effort.
--
 Pete Gontier, CTO, Integer Poet Software; [e-mail]

 "...where they burn books, people are next." -- XTC

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Mon, 13 Jun 1994 00:06:49 -0700
Organization: Internet for the Olympic Peninsula

In article <[e-mail]>, [e-mail] (Pete Gontier)
wrote:

> [e-mail] (Alex Metcalf) writes:
>
> >Up until a few weeks ago I thought it was impossible to read
> >information such as which Finder windows are open, the positions of
> >icons in that window (I know that's in the DB, but I don't know how
> >to check for the open window), etc. However, Popup Folder lets you
> >click on a finder folder and see some stuff about its hierarchy. So
> >there MUST be a way! Also, that screen saver software that has stuff
> >interacting with your finder windows.
>
> The question is not whether it can be done or how it can be done. Those
> are comparatively easy questions, and I will take a swipe at answering
> them below. The really interesting question, however, is this: do you
> really want to?
>
> ... [Reverse engineering 1.01 omitted]
>
> The second part of the question is more of the same. Assuming you want
> to put in this kind of work, are you willing to put in this kind of work
> for System 7, System 7.1, System 7 Pro, and System 7.5? How about System
> 6 and for each version of the System before? And each version of the
> System after 7.5? Because the information is different in all of these
> cases.
>
> I'm not trying to be a wet blanket, but I do feel like I ought to try to
> discourage you for your own good. You can do it; I've done it. But you
> had better be sure it's worth the effort.

Particulary, does he want to do this for System 7.5, whose Finder is happy
to tell you:

tell application "Finder"
    get every window
end tell

will return something like this (translated to text, from its list of
objects form):
    {window of folder "HyperCard 2.2" of startup disk of application
"Finder", window of startup disk of application "Finder"}

And
tell application "Finder"
    get name of every window
end tell

will return just the names, if that's all you want:  {"HyperCard 2.2",
"Vashon"}

Seems a whole lot simpler to me.  [Alex's own app can send the necessary
event.]

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   No hablo Intel.
   [e-mail]

---------------------------

>From [e-mail] (Jonathan Kimmitt)
Subject: Metrowerks code generation wierdness
Date: 6 Jun 94 21:10:45 GMT
Organization: Cambridge Consultants Limited

Has anybody noticed that Metrowerks DR/2 and DR/3 return values from
functions
in different registers depending on what the function result type is ?

a function such as 'char *xmalloc(long)' returns in A0
whereas a function such as 'long temps(void)' returns in D0

No other compiler that I have ever seen for the 68K does this. ANSI C
allows this,
but as far as I can see it is impossible to guarantee correct code unless
'require prototypes' is checked, which makes it more difficult to port
old non ANSI (K&R) code.

For the above functions declared in file A (xmalloc is a function which
allocates
memory), if file B contains

    {
    struct junk *ptr = (struct junk *)xmalloc(sizeof(struct junk));
    .....


incorrect code will be generated if your forget to use the prototype
because xmalloc will be assumed to return int and the value to be put in
ptr
will be assumed to be in D0, whereas the actual function will put the
result in A0
before returning. The result is that ptr will end up pointing to a random
location
in memory and will most likely cause a bus error or crash your mac.

THINK C (with 4-byte ints on), MPW and gcc will handle this case
correctly, so if
you are porting to Metrowerks you might not notice this bug in your code
until
it is too late.

One might speculate that this feature was implemented to improve
efficiency, since theoretically a pointer returned in A0 can be used
immediately. In practise it means
that code resources developed with Metrowerks might not be able to be
used with another compiler
if they return pointers, and vice versa. Since this is a compatability
issue, one would
expect that this feature should be made optional. Your constructive
comments are invited ...

+++++++++++++++++++++++++++

>From [e-mail] (Zalman Stern)
Date: Tue, 7 Jun 1994 01:26:27 GMT
Organization: Adobe Systems Incorporated

Jonathan Kimmitt writes
> One might speculate that this feature was implemented to improve
> efficiency, since theoretically a pointer returned in A0 can be used
> immediately. In practise it means
> that code resources developed with Metrowerks might not be able to be
> used with another compiler
> if they return pointers, and vice versa. Since this is a compatability
> issue, one would
> expect that this feature should be made optional. Your constructive
> comments are invited ...

The 68k Macintosh has no standard C calling convention. The solution for
things like code resources is to use the Pascal calling convention for every
cross-interface call. In a couple years, PowerPC will have totally taken
over and such concerns (along with A5 and A4 worlds) will be but dim
nightmares from the past.
--
Zalman Stern           [e-mail]            [phone]
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
   Never let a "final candidate" subscript get above the age of consent.

+++++++++++++++++++++++++++

>From [e-mail] (John McEnerney)
Date: Tue, 7 Jun 1994 15:42:08 GMT
Organization: The World Public Access UNIX, Brookline, MA


>a function such as 'char *xmalloc(long)' returns in A0
>whereas a function such as 'long temps(void)' returns in D0
>
>No other compiler that I have ever seen for the 68K does this. ANSI C
>allows this,
>but as far as I can see it is impossible to guarantee correct code unless
>'require prototypes' is checked, which makes it more difficult to port
>old non ANSI (K&R) code.

As far as the ANSI standard is concerned, it would never be correct to
call a function defined as returning a pointer when there is no
declaration in scope. You cannot assume that 'int' and 'pointer' have the
same representation, and we are allowed to use different calling
conventions for them.

You can force the compiler to return pointers in D0 (this is sometimes
necessary for calling C code generated by the MPW compiler) by using

#pragma pointers_in_D0

-- John McEnerney, Metrowerks PowerPC Product Architect


+++++++++++++++++++++++++++

>From [e-mail] (Altan J. Stalker)
Date: Tue, 7 Jun 1994 15:23:57 GMT
Organization: Indiana University, Bloomington IN

In article <[e-mail]>, Jonathan Kimmitt <[e-mail]> wrote:
>Has anybody noticed that Metrowerks DR/2 and DR/3 return values from
>functions
>in different registers depending on what the function result type is ?
>
> [stuff deleted]
>
> ... Since this is a compatability
> issue, one would
> expect that this feature should be made optional. Your constructive
> comments are invited ...

Although I have never used it, a pragma exists to turn this feature
on and off.

pointers_in_A0   Make functions return pointers in the 68000 register A0
         [default]

pointers_in_d0   Make functions return pointers in the 68000 D0 register
                 [what you wanted]

(this is from the _Metrowerks C Language Reference DR/2_ page 13)

--
Altan J. Stalker, Indiana University, Bloomington IN
[e-mail]






+++++++++++++++++++++++++++

>From [e-mail] (Bruce Hoult)
Date: Wed, 8 Jun 1994 16:13:53 +1200 (NZST)
Organization: (none)

[e-mail] (Zalman Stern) writes:
> The 68k Macintosh has no standard C calling convention. The solution for
> things like code resources is to use the Pascal calling convention for every
> cross-interface call. In a couple years, PowerPC will have totally taken
> over and such concerns (along with A5 and A4 worlds) will be but dim
> nightmares from the past.

... to be replaced by new nightmares such as having to remember to put all
floating point paramaters after all integer parameters, if you want them
to fit into registers :-(

-- Bruce "anyone who designs a calling convention around k&r should be shot" Hoult

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Wed, 08 Jun 1994 00:36:39 -0700
Organization: Internet for the Olympic Peninsula

In article <[e-mail]>, [e-mail]
(Bruce Hoult) wrote:

>
> ... to be replaced by new nightmares such as having to remember to put all
> floating point paramaters after all integer parameters, if you want them
> to fit into registers :-(

Wouldn't have been necessary if the ANSI folks had required prototypes
instead of offering them as a no-cost extra.  [That would have probably
exceeded the subcommittee's charter, since it would not have codified
existing practice, but broken new ground.  It WOULD have produced a better
language, though.]

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   No hablo Intel.
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jon Wdtte)
Date: 9 Jun 1994 09:15:16 GMT
Organization: The Royal Institute of Technology

In <[e-mail]> [e-mail] (Jonathan Kimmitt) writes:

>a function such as 'char *xmalloc(long)' returns in A0
>whereas a function such as 'long temps(void)' returns in D0

>No other compiler that I have ever seen for the 68K does this. ANSI C

Most non-mac compilers for the 68K I've seen does this.

You can turn it off with #pragma pointers_in_D0

cheers,

                    / h+
--
 -- Jon W{tte, [e-mail], Mac Software Engineer Deluxe --

 -- I don't fear death, it's dying that scares me.

+++++++++++++++++++++++++++

>From [e-mail] (Gary Kacmarcik)
Date: 09 Jun 1994 14:30:42 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)


In article <[e-mail]> [e-mail] (Bruce Hoult) writes:
>
> [e-mail] (Zalman Stern) writes:
> > [...]   In a couple years, PowerPC will have totally taken
> > over and such concerns (along with A5 and A4 worlds) will be but dim
> > nightmares from the past.
>
>  ... to be replaced by new nightmares such as having to remember to put all
> floating point paramaters after all integer parameters, if you want them
> to fit into registers :-(

i don't know what you mean by this.  the PowerPC calling conventions that
i'm familiar with do not require this.

for the PowerPC, standard function calling conventions state that fixed-
point arguments go in r3-r10, floating-point arguments go in fr1-fr13.

if you define something like:

   int foo(int a,float b,int c,double d)

the parameters will be mapped to registers as follows:
  a:  r3
  b:  fr1
  c:  r4
  d:  fr2

according to this ABI, it is explicitly stated that parameters can be
declared in any order, and the fixed- and floating-point registers will
be used as efficiently as possible.

-gary j kacmarcik
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (John McEnerney)
Date: Thu, 9 Jun 1994 15:09:56 GMT
Organization: The World Public Access UNIX, Brookline, MA

[e-mail] (Gary Kacmarcik) writes:

>if you define something like:
>   int foo(int a,float b,int c,double d)
>the parameters will be mapped to registers as follows:
>  a:  r3
>  b:  fr1
>  c:  r4
>  d:  fr2

WRONG! (You would think this would be the case, but it is not)

a: r3
b: fr1 (r4 is reserved)
c: r5
d: fr2 (r6 and r7 are reserved)

additional integer arguments go in r8, etc. This is a strange nuance to
the IBM PowerPC ABI. I believe that it is used for calling functions
which have no prototype in scope, e.g. if I call printf() without
including <stdio.h> (which is illegal in ANSI) the compiler will pass the
floating-point arguments in -both- the integer and floating-point
registers, so the callee can work correctly no matter if it takes a
variable number of arguments or has arguments declared as floating-point
types. Note that as the original poster pointed out, you get best results
by declaring your integer arguments first and then your floating-point
arguments.

The CodeWarrior compiler does not implement this feature, since the ANSI
standard us strict on this issue (it is illegal to call a function taking
a variable number of arguments without a prototype) However, for
compatibility with the Apple Toolbox and such, we incur the same penalty
in register usage.

-- John McEnerney, Metrowerks PowerPC Product Architect


+++++++++++++++++++++++++++

>From [e-mail] (Bruce Hoult)
Date: Fri, 10 Jun 1994 16:45:43 +1200 (NZST)
Organization: (none)

[e-mail] (Gary Kacmarcik) writes:
> >  ... to be replaced by new nightmares such as having to remember to put all
> > floating point paramaters after all integer parameters, if you want them
> > to fit into registers :-(
>
> i don't know what you mean by this.  the PowerPC calling conventions that
> i'm familiar with do not require this.
>
> for the PowerPC, standard function calling conventions state that fixed-
> point arguments go in r3-r10, floating-point arguments go in fr1-fr13.
>
> if you define something like:
>
>    int foo(int a,float b,int c,double d)
>
> the parameters will be mapped to registers as follows:
>   a:  r3
>   b:  fr1
>   c:  r4
>   d:  fr2
>
> according to this ABI, it is explicitly stated that parameters can be
> declared in any order, and the fixed- and floating-point registers will
> be used as efficiently as possible.

Would that it were so!

Unfortunately, this directly contradicts Apple's _Inside Macintosh: PowerPC
System Software_, page 1-50:

"Placing a floating point parameter into a floating point register also
reserves one or two genrral-purpose registers, depending on whether the
paramater is 32 or 64 bits long.  This behavious is dictated in order to
support the ability of a C function to call another function without
knowing the number or types of the callee's parameters. [...]  The only
difference betwen cases in which the prototype is available and cases
in which the prototype isn't available is that the floating point
parameters are copied into the general-purpose register(s) in the latter
case but not in the former."

[there follows an example of register mapping]

"NOTE.  It would have been possible to pas all the fixed point values in
registers if the floating-point parameters had been grouped at the end of
the parameter list".


I would *love* to learn that this is wrong.

-- Bruce

+++++++++++++++++++++++++++

>From [e-mail] (Gary Kacmarcik)
Date: 10 Jun 1994 20:22:51 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)

In article <[e-mail]> [e-mail] (John McEnerney) writes:
>
> [e-mail] (Gary Kacmarcik) writes:
>
> >if you define something like:
> >   int foo(int a,float b,int c,double d)
> >the parameters will be mapped to registers as follows:
> >  a:  r3
> >  b:  fr1
> >  c:  r4
> >  d:  fr2
>
> WRONG! (You would think this would be the case, but it is not)

i looked this up when i got home and discovered that what i was describing
was the *Embedded* ABI, which apparently has a more intelligent way
of allocating registers.  it also has things like not always generating
the (typically unused) 'param area' to shadow the GPR's on the stack -
it only generates a param area if it's needed.

apparently the embedded people care more about having proper register and
stack allocation and are willing to forsake screwy calling conventions
to get it.  ;-)

it's funny that i never came across an example that exposed this - i guess
i don't do as much floating-point code as i thought.


-gary j kacmarcik
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Zalman Stern)
Date: Sat, 11 Jun 1994 01:30:31 GMT
Organization: Adobe Systems Incorporated

Gary Kacmarcik writes
> apparently the embedded people care more about having proper register and
> stack allocation and are willing to forsake screwy calling conventions
> to get it.  ;-)

The embedded people have the advantage of defining their calling convention
four years later when it is obvious what you can and cannot realistically
depend on in ANSI-C code. They are also willing to sacrifice a little more
for performance. (I.e. portability is less of a concern in embedded code.)
--
Zalman Stern           [e-mail]            [phone]
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
   Never let a "final candidate" subscript get above the age of consent.

+++++++++++++++++++++++++++

>From [e-mail] (Bruce Hoult)
Date: Sun, 12 Jun 1994 21:03:48 +1200 (NZST)
Organization: (none)

[e-mail] (Gary Kacmarcik) writes:
> i looked this up when i got home and discovered that what i was describing
> was the *Embedded* ABI, which apparently has a more intelligent way
> of allocating registers.  it also has things like not always generating
> the (typically unused) 'param area' to shadow the GPR's on the stack -
> it only generates a param area if it's needed.
>
> apparently the embedded people care more about having proper register and
> stack allocation and are willing to forsake screwy calling conventions
> to get it.  ;-)
>
> it's funny that i never came across an example that exposed this - i guess
> i don't do as much floating-point code as i thought.

Agreed that it's screwy (I have to -- I'm the one that started this :-),
but there are some nice things in the PPC calling conventions as well, most
of them designed to make tiny functions extremely efficient.

For example, it's really nice that you can quite legally push a few things
on the stack without adjusting the stack pointer, because you can depend
on interrupt routines always skipping over the first couple of hundred
bytes of stack, in case you're using it.

It's also neat that a function like...

  long myAdd(long a, long b){return a+b;}

...can be compiled into just...

  add r3,r3,r4
  blr

...which results in no memory access at all (other than instruction
fetch).  Most 68k compilers will give even this function the full
treatment...

  link a6,#0
  move.l 8(a6),d0
  add.l 12(a6),d0
  unlk a6
  rts

... not to mention the caller setting up the stack beforehand, and
cleaning off the parameters afterwards, causing eight memory references
in using this little function (ten for Pascal calling conventions)

In fact, on many code examples I've looked at, the PPC code is actually
*smaller* than the equivalent 68K code generated by the MPW or Symantec
compilers.

-- Bruce

+++++++++++++++++++++++++++

>From [e-mail] (Gary Kacmarcik)
Date: 12 Jun 1994 18:18:31 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)

In article <[e-mail]> [e-mail] (Bruce Hoult) writes:
>
> Agreed that it's screwy (I have to -- I'm the one that started this :-),
> but there are some nice things in the PPC calling conventions as well, most
> of them designed to make tiny functions extremely efficient.
>
> For example, it's really nice that you can quite legally push a few things
> on the stack without adjusting the stack pointer, because you can depend
> on interrupt routines always skipping over the first couple of hundred
> bytes of stack, in case you're using it.

hmmm... i don't think that i would have chosen this particular example to
try to demonstrate why the calling conventions _weren't_ screwy.  ;-)
when i first saw IBM's compiler generating code that placed values above
the stack ptr, my first response was <ick>.

i can deal with it now that i understand that the compiler's trying to insure
that r1 is always pointing to a value stack frame.  one thing i wonder about
(but have yet to try) is how alloca() is handled.

overall, the calling conventions aren't bad and there are many advantages.
but there certainly are wierdnesses.


gary j kacmarcik
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Bruce Hoult)
Date: Mon, 13 Jun 1994 19:41:53 +1200 (NZST)
Organization: (none)

[e-mail] (Gary Kacmarcik) writes:
> > For example, it's really nice that you can quite legally push a few things
> > on the stack without adjusting the stack pointer, because you can depend
> > on interrupt routines always skipping over the first couple of hundred
> > bytes of stack, in case you're using it.
>
> hmmm... i don't think that i would have chosen this particular example to
> try to demonstrate why the calling conventions _weren't_ screwy.  ;-)
> when i first saw IBM's compiler generating code that placed values above
> the stack ptr, my first response was <ick>.
>
> i can deal with it now that i understand that the compiler's trying to insure
> that r1 is always pointing to a value stack frame.  one thing i wonder about
> (but have yet to try) is how alloca() is handled.
>
> overall, the calling conventions aren't bad and there are many advantages.
> but there certainly are wierdnesses.

The way I look at it is that most of this stuff has been designed to be
fast running, even if it make life hell for the asm programmer trying to
keep track of things manually.  That, after all, being what compilers
are for.

-- Bruce

---------------------------

>From [e-mail] (Anton Rang)
Subject: PPC and 64-bit video (was Re: Fast full screen scrolling: impossible?)
Date: 13 Jun 1994 02:33:06 GMT
Organization: Minnesota Angsters

In article <[e-mail]> [e-mail] writes:
>d e v e l o p 18 claims that the PPC blitter that they used was slower than
>CopyBits because it didn't (presumably, for some unknown reason, *couldn't*)
>take advantage of the 64-bit path of video.

  Unless you're using the floating-point registers, you can't use the
full 64-bit path efficiently, because there's no 64-bit integer load.
I haven't looked at NQDCopyBits to see if it uses the FP registers; I
suppose that it *could*, in cases where there is no scaling, shifting,
etc. but it seems unlikely that it would.

>For this same reason, *BlockMove* was also slower.

  Well, BlockMove is going to be slower on the PPC because the video
memory is noncachable and BlockMove will pre-zero it using the dcbz
instruction ('zero-cache-block').  Using dcbz is a big win when doing
copies between cachable blocks, because it eliminates the pre-read
that the processor will otherwise do when storing data.

  The Power Macintosh NuBus technical note addresses this, and
includes a new interface, PBBlockMove, which is supposed to take into
account the cachability of source and destination memory ranges.  (No
word on when this will be shipping or whether it will be licensable as
a system extension.)

>What is going on with the memory subsystem in the PowerMacs? Is it or isn't it
>64-bit? Is the DRAM video 64-bit? Is the AV video? Is the non-AV PDS video?

  The non-AV PDS VRAM is 64-bit, the DRAM is 64-bit (all of memory
is).  The AV bus internally is 32-bits (it's the same chips as on the
680x0 AVs), but might have a 64-bit interface to the processor bus; I
haven't looked.

> [ questions about video bandwidth deleted, i have no answers ]
>For that matter, why can't BlockMove move data in 64-bit chunks when
>it is most optimal to do so?

  It can.  The problem is the dcbz, which when used with video memory
will result in every word being written twice.  That's why you should
use CopyBits instead.  :-)

>And finally, what happened to the load/store multiple instructions
>that are (I assume?) faster on the 601, but will probably be slower
>"in future implementations?"

  They're actually not faster on the 601, they simply take less code
space.  They still take one cycle per register to process.  I haven't
checked to see whether they're slower on the 603/604, but would guess
that they may cause synchronization on the 603, which would certainly
slow things down relative to just using plain load/store.

  The fastest way to move memory on the 601 is to use floating-point
registers (load/store double), coupled with 'dcbz' if you're going to
cachable memory, but *not* when you're going to non-cachable memory.
(All of this presumes aligned memory, incidentally; if you're not
aligned, you're out of luck and probably need to use the string
instructions instead.)
--
Anton Rang ([e-mail])

---------------------------

>From Frank Manshande <[e-mail]>
Subject: Playing QuickTime movies
Date: Mon, 6 Jun 1994 11:41:21 GMT
Organization: AND Software BV

Hi,

I have a question concerning playing QuickTime movies.

What I want is to store the movie (data) into the datafork at
a specific offset (for example at offset 3000), and later play
that movie from that offset. This way I can put more than one
QuickTime movie into one file and play a movie at a specific
offset.

The call "PutMovieIntoDataFork" only seems to store the movie
structure, and not the movie data, into a file at the specified
offset. This way the PutMovieIntoDataFork call creates a file
of about 1,5 KB which only contains a reference to the original
movie data file.

Does anybody have suggestions? I would be very grateful!

Frank Manshande
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Ron Breger)
Date: Mon, 6 Jun 1994 17:49:45 GMT
Organization: Netcom

Frank Manshande ([e-mail]) wrote:
: Hi,

: I have a question concerning playing QuickTime movies.

: What I want is to store the movie (data) into the datafork at
: a specific offset (for example at offset 3000), and later play
: that movie from that offset. This way I can put more than one
: QuickTime movie into one file and play a movie at a specific
: offset.

: The call "PutMovieIntoDataFork" only seems to store the movie
: structure, and not the movie data, into a file at the specified
: offset. This way the PutMovieIntoDataFork call creates a file
: of about 1,5 KB which only contains a reference to the original
: movie data file.

I am having the same problem, but I am using handles.
This is something that I'm trying to do:


// save the moive
PutMoiveIntoHandle()
AddResource(publicMoive, 'MRES', 1000, "");
ReleaseResource(publicMovie);

then

// play the movie
publicMovie = GetResource('MRES',1000);
DetachResource(publicMoive);
StartMoive(publicMoive);


I would like to have one (resource) file to contain many movies.
I don't want to use MovieFiles.  I would like the data
to be in a resource and not contain any references to
the original files.  Is this possible?

Please help.  (email or post).

Thanks.
Ron Breger

--
=====================================================================
Ron Breger
[e-mail]                              AppleLink: RON.BREGER
=====================================================================

+++++++++++++++++++++++++++

>From [e-mail] (Ivan M CaveroBelaunde)
Date: Mon, 6 Jun 1994 20:27:32 GMT
Organization: The World Public Access UNIX, Brookline, MA

[e-mail] (Ron Breger) writes:
>Frank Manshande ([e-mail]) wrote:
>: Hi,
>: I have a question concerning playing QuickTime movies.
>: What I want is to store the movie (data) into the datafork at
>: a specific offset (for example at offset 3000), and later play
>: that movie from that offset. This way I can put more than one
>: QuickTime movie into one file and play a movie at a specific
>: offset.

FlattenMovieData to a temp file, then copy the data over, using
SetMediaDataRef to repoint all the medias in the movie to the new file.

>I am having the same problem, but I am using handles.
>This is something that I'm trying to do:

>// save the moive
>PutMoiveIntoHandle()
>AddResource(publicMoive, 'MRES', 1000, "");
>ReleaseResource(publicMovie);

This would work in theory; however, you should do a WriteResource
before you do a ReleaseResource. Is there a reason why you're not using
Add/UpdateMovieResource, however?

>then

>// play the movie
>publicMovie = GetResource('MRES',1000);
>DetachResource(publicMoive);
>StartMoive(publicMoive);

This will *not* work. You'd have to do:
    myMovie = NewMovieFromHandle(publicMovie);

>I would like to have one (resource) file to contain many movies.

Perfectly feasible with Add/UpdateMovieResource, since you can specify
the resID, as well as scan the movie res file for 'moov' resources.

>I don't want to use MovieFiles.

Why? Are there limitations you see in using them?

>  I would like the data
>to be in a resource and not contain any references to
>the original files.  Is this possible?

Nope. The movie *data* must be in a data fork. It *is* possible for the
file to be completely self-contained (ie all the movie data would be in
the data fork of the file that contains the movie resources), however.

-Ivan
- -
Ivan Cavero Belaunde ([e-mail])
Avid VideoShop Project Lead
Avid Technology, Inc.

+++++++++++++++++++++++++++

>From Frank Manshande <[e-mail]>
Date: Tue, 7 Jun 1994 07:29:44 GMT
Organization: AND Software BV

In article <[e-mail]> Ivan M CaveroBelaunde,
[e-mail] writes:
>FlattenMovieData to a temp file, then copy the data over, using
>SetMediaDataRef to repoint all the medias in the movie to the new file.
>

I'm reading IM-QuickTime right now, but I can't seem to find how I can
play a movie from a specific offset. If I succeed in saving the movie
the way you describe, using SetMediaDataRef for all the tracks, how can
I then play that movie. And would that also work under QuickTime for
Windows?

Thanks for your time!

Frank Manshande
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Ivan M CaveroBelaunde)
Date: Tue, 7 Jun 1994 13:50:44 GMT
Organization: The World Public Access UNIX, Brookline, MA

Frank Manshande <[e-mail]> writes:

>In article <[e-mail]> Ivan M CaveroBelaunde,
>[e-mail] writes:
>>FlattenMovieData to a temp file, then copy the data over, using
>>SetMediaDataRef to repoint all the medias in the movie to the new file.
>>

>I'm reading IM-QuickTime right now, but I can't seem to find how I can
>play a movie from a specific offset. If I succeed in saving the movie
>the way you describe, using SetMediaDataRef for all the tracks, how can
>I then play that movie. And would that also work under QuickTime for
>Windows?

The way you would play that movie is that you would, in that same file,
store multiple movie resources for each of the movies stored at different
offsets using Add/UpdateMovieResource. Then you can just do
NewMovieFromFile/FromHandle and play whichever one you want.

This does *not* work at all under QuickTime for Windows, since QTW
uses data-fork only movies. Since df movies are defined to contain
its "movie resource" at the end of the data stream, you can only
have *one* movie per file, unlike the flexibility you have when you
use moov resources.

QTW has a number of other limitations you might want to read up on. I don't
remember them off the top of my head, but, for exmaple, I don't believe
multitrack or multifile (dependent file) support is in there yet - you're
limited to comlletely self-contained movies with at most 1 video track and
1 audio track.

-Ivan
- -
Ivan Cavero Belaunde ([e-mail])
Avid VideoShop Project Lead
Avid Technology, Inc.

+++++++++++++++++++++++++++

>From [e-mail] (Ron Breger)
Date: Wed, 8 Jun 1994 15:39:47 GMT
Organization: Netcom

: >I am having the same problem, but I am using handles.
: >This is something that I'm trying to do:

: >// save the moive
: >PutMoiveIntoHandle()
: >AddResource(publicMoive, 'MRES', 1000, "");
: >ReleaseResource(publicMovie);
 I did the WriteResource.


: This would work in theory; however, you should do a WriteResource
: before you do a ReleaseResource. Is there a reason why you're not using
: Add/UpdateMovieResource, however?

: >then

: >// play the movie
: >publicMovie = GetResource('MRES',1000);
: >DetachResource(publicMoive);
: >StartMoive(publicMoive);

: This will *not* work. You'd have to do:
:     myMovie = NewMovieFromHandle(publicMovie);

Yes, I am doing the NewMovieFromHandle.

: Perfectly feasible with Add/UpdateMovieResource, since you can specify
: the resID, as well as scan the movie res file for 'moov' resources.

: >I don't want to use MovieFiles.

: Why? Are there limitations you see in using them?

I want to use my own resources instead of MovieFiles, so that I can
put all the movies in regular resource files and use ResEdit to copy
and paste the movies I need.  Also, I would like to have my application
contain all the resources it needs and not have it depend on any
other files.

I am planning of using QuickTime 2.0 that supports Music (MIDI) and
would like to have all of the Movies be in the resource fork of the
application.  I find it very convienient to be able to use ResEdit
to copy/paste resources around.  So, I was trying to have a movie
be self-contained, storing the movie as a resource, and reading it
back in using GetResource() and NewMoiveFromHandle(), but have been
unsuccessful.  I still am a little confused why this doesn't work:

AddResource(publicMoive, 'MRES', 1000, "");
WriteResource(publicMovie);
ReleaseResource(publicMovie);

[I don't want to use AddMoiveResource(), as I don't want to use
MoiveFiles().  I want all the data to be in one resource and not use
the data fork.  That way, I can use ResEdit to eaisly copy/paste
movies around.  This is what I do with my 'snd ' resources!]

then

// play the movie
publicMovie = GetResource('MRES',1000);
DetachResource(publicMoive);
NewMovieFromHandle(&theMovie, publicMovie);
StartMoive(theMoive);

Thanks for all your help.
--
=====================================================================
Ron Breger
[e-mail]                              AppleLink: RON.BREGER
=====================================================================

+++++++++++++++++++++++++++

>From [e-mail] (John Wang)
Date: 9 Jun 1994 21:37:17 GMT
Organization: Apple Computer, Inc.

There are two parts to a movie.  1) the movie data atom.  2) the movie
resource atom.  The movie data atom is always in the data fork.   However,
the movie resource atom can be stored in either the resource fork or the
data fork.  If the movie resource atom is stored in the resource fork, it
is very easy to randomly access the many atoms that you might have stored
in individual resources.  But, if you want your movies to be cross-platform
compatible, then you'll want to stored the movie resource atoms in the data
fork.

To store the movie data atom into a file, you must call either FlattenMovie
or FlattenMovieData.  The difference between FlattenMovie and FlattenMovie
is that FlattenMovie also adds the movie resource atom to the resource
fork.  Therefore, you'll want to call FlattenMovieData if you don't want to
add a movie resource atom to the resource fork.  Instead, in either call,
you can use the flag, flattenAddMovieToDataFork.  This will add the movie
resource atom to the data fork.

For a more complete discussion of this topic, please read my column on
"Movie Files" in issue #16 of develop magazine (an Apple publication).

John Wang

In article <[e-mail]>, [e-mail] (Ron Breger)
wrote:

> Frank Manshande ([e-mail]) wrote:
> : Hi,
>
> : I have a question concerning playing QuickTime movies.
>
> : What I want is to store the movie (data) into the datafork at
> : a specific offset (for example at offset 3000), and later play
> : that movie from that offset. This way I can put more than one
> : QuickTime movie into one file and play a movie at a specific
> : offset.
>
> : The call "PutMovieIntoDataFork" only seems to store the movie
> : structure, and not the movie data, into a file at the specified
> : offset. This way the PutMovieIntoDataFork call creates a file
> : of about 1,5 KB which only contains a reference to the original
> : movie data file.
>
> I am having the same problem, but I am using handles.
> This is something that I'm trying to do:
>
>
> // save the moive
> PutMoiveIntoHandle()
> AddResource(publicMoive, 'MRES', 1000, "");
> ReleaseResource(publicMovie);
>
> then
>
> // play the movie
> publicMovie = GetResource('MRES',1000);
> DetachResource(publicMoive);
> StartMoive(publicMoive);
>
>
> I would like to have one (resource) file to contain many movies.
> I don't want to use MovieFiles.  I would like the data
> to be in a resource and not contain any references to
> the original files.  Is this possible?
>
> Please help.  (email or post).
>
> Thanks.
> Ron Breger
>
> --
> =====================================================================
> Ron Breger
> [e-mail]                              AppleLink: RON.BREGER
> =====================================================================

+++++++++++++++++++++++++++

>From [e-mail] (Ivan M CaveroBelaunde)
Date: Mon, 13 Jun 1994 21:56:13 GMT
Organization: The World Public Access UNIX, Brookline, MA

[e-mail] (Ron Breger) writes:
>I want to use my own resources instead of MovieFiles, so that I can
>put all the movies in regular resource files and use ResEdit to copy
>and paste the movies I need.  Also, I would like to have my application
>contain all the resources it needs and not have it depend on any
>other files.

QT usually *needs* to store movie data in the data fork of files. QT2
introduces a "handle data handler," which allows you to create movies
that are held entirely in memory. (Maynard Handley will like this...)
The twist is, of course, that you have to save them yourself somehow
(the movie user data could be the place for it).

So the movie creation process goes as follows:
  - Create the movie the usual way, putting the data in the data fork.
  - After you're done, make a copy of the movie by copying each
     track by hand (using InsertTrackSegment). However, on the
     copied movie, when you create the media, specify that you're
     using the handle data handler instead of the alias data
     handler. This will create an in-memory copy of the
     movie data.
  - Save the handles where the data is sitting in the movie's user
     data using AddUserData.
  - Do the PutMovieIntoHandle, etc, stuff and save the movie as a
     resource.

Once you've done that once, you can load the movie by doing the following:
  - GetResource()
  - NewMovieFromHandle()
  - GetMovieUserData()
  - For every track in this movie, if the media type is 'hndl',
         use the SetMediaDataRef call to "repoint" the media
         to the handle from GetMovieUserData.

Although I haven't tried this specifically, I've used all of these calls
at one time or another, so it should work.

The downside to this trick is that you end up with two copies of the
data in memory, which for large movies would be a serious issue.
That can be addressed by putting the data handle in a separate resource
instead of the user data, but the drawback there is that you must
copy two resources around, which might or might not be a big deal.
You could still use the movie user data to specify the res type and id
where the data is stored.

Hope this helps,

-Ivan
- -
Ivan Cavero Belaunde ([e-mail])
Avid VideoShop Project Lead
Avid Technology, Inc.
#include <std.disclaimer.h>

---------------------------

>From [e-mail] (John Nagle)
Subject: Quickdraw GX - Why?
Date: Mon, 30 May 1994 03:46:07 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

      Well, we now have Quickdraw GX, which is a 2D object-oriented
graphics system.  This is nice, but does it solve a real problem?
It's not a full 3D system, so you can't use it for 3D graphics.
It's not compatible with existing object-oriented graphics standards,
like X or PHIGS.  It's complicated; several volume of manuals are required.
Rescalable icons are nice, but Quickdraw GX seems overkill just to
achieve that.  What kind of application would be simpler if written to use
Quickdraw GX?

                    John Nagle

+++++++++++++++++++++++++++

>From [e-mail] (David Opstad)
Date: 29 May 1994 22:01:29 -0700
Organization: Apple Computer Inc, Cupertino, CA

In article <[e-mail]>, John Nagle <[e-mail]> wrote:
>      Well, we now have Quickdraw GX, which is a 2D object-oriented
>graphics system.  This is nice, but does it solve a real problem?
>It's not a full 3D system, so you can't use it for 3D graphics.
>It's not compatible with existing object-oriented graphics standards,
>like X or PHIGS.  It's complicated; several volume of manuals are required.
>Rescalable icons are nice, but Quickdraw GX seems overkill just to
>achieve that.  What kind of application would be simpler if written to use
>Quickdraw GX?

A word processing or page layout app would be much simpler using GX, since the
typographic expressiveness built into GX is very great. An application that
wishes to print to multiple kinds of paper in the same job (portrait and
landscape, say, or throw in an envelope too) has an easy road using GX printing.
Printing transfer modes (including to PostScript (TM) printers) that you
couldn't used to print is now possible with GX. Having pictures that are both
parsable and able to themselves contain pictures makes for much easier handling
of whole trees of image data to be rendered. And so on...

GX definitely isn't just for 2D graphics. Of course, your points about 3D are
well-taken, but that wasn't the problem that GX was intended to solve. For
years, developers for apps on the Mac have had to put up with a lot of quirks
in the way that QuickDraw forced them to deal with device-dependent graphics,
and with printing that also had its share of strange hackishness. GX finally
fixes many of these problems.

Dave Opstad
GX Line Layout Weenie

+++++++++++++++++++++++++++

>From [e-mail] (Jon Wdtte)
Date: 30 May 1994 07:43:14 GMT
Organization: The Royal Institute of Technology

In <[e-mail]> [e-mail] (John Nagle) writes:

>      Well, we now have Quickdraw GX, which is a 2D object-oriented
>graphics system.  This is nice, but does it solve a real problem?

Yes.

>It's not compatible with existing object-oriented graphics standards,
>like X or PHIGS.

1) X is not object oriented; it's QuickDraw where the bottlenecks
   go through a network driver.
2) PHIGS is a 3D library.

>It's complicated; several volume of manuals are required.

Would you rahter it was less capable? The documentation for QDGX is
quite good to my meaning, what's missing is a lot of sample code (there
is some at least) and support in our frameworks of choise.

>Rescalable icons are nice, but Quickdraw GX seems overkill just to
>achieve that.  What kind of application would be simpler if written to use
>Quickdraw GX?

QuickDraw GX printing is not a, but SEVERAL steps up, and re-defines
desktop printing. It shoots Apple ahead of the competition.

The GX imaging model has several things going for it, both in simplicity
and capability. You can write a capable draw program with much less effort
than before. You can expect to see shareware programs going after the
Illustrator and FreeHand crowd!

It's also _much_more_capable_ with ligatures, special forms and kerning
handled automatically, as well as providing very good typographic control
("Gunk" and "Funk" axes, anyone? :-)

If you can't see the use of this to create more beautiful documents,
you're positioned where one-font-only people were in the middle of
the 80s.

Cheers,

                    / h+
--
 -- Jon W{tte, [e-mail], Mac Software Engineer Deluxe --
 Engineering: "How will this work?" Science: "Why will this work?" Management:
 "When will this work?"  Liberal Arts: "Do you want fries with that?"
                     -- Jesse N. Schell

+++++++++++++++++++++++++++

>From [e-mail] (Daniel R. Kegel)
Date: 30 May 1994 07:55:28 GMT
Organization: California Institute of Technology, Pasadena

In article <[e-mail]>, John Nagle <[e-mail]> wrote:
>      Well, we now have Quickdraw GX, which is a 2D object-oriented
>graphics system.  This is nice, but does it solve a real problem?

Quickdraw GX supports Unicode, which means that software
will be easier to internationalize.  Although the application developer
still needs to worry about different character sets when talking to
the outside world, inside everything can be Unicode.  This makes document
exchange and maintenance easier in a multilingual environment.
- Dan

+++++++++++++++++++++++++++

>From [e-mail] (Michael Peirce)
Date: Mon, 30 May 94 09:58:47 PST
Organization: Peirce Software, Inc.


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (John Nagle) writes:
>       Well, we now have Quickdraw GX, which is a 2D object-oriented
> graphics system.  This is nice, but does it solve a real problem?
> It's not a full 3D system, so you can't use it for 3D graphics.
> It's not compatible with existing object-oriented graphics standards,
> like X or PHIGS.  It's complicated; several volume of manuals are required.
> Rescalable icons are nice, but Quickdraw GX seems overkill just to
> achieve that.  What kind of application would be simpler if written to use
> Quickdraw GX?

For me the two most important parts of QuickDraw GX aren't specific
to it's graphics engine: Typography and Printing.

QuickDraw GX typography brings truly great type handling to "normal"
programs with the line layout manager.  No longer will this be limited
to page layout programs.  Related is the new font technology: support
for TrueType GX and Type 1 multi master fonts.  These fonts allow
for smarts to be put directly into the font to do things that wasn't
possible before.

QuickDraw GX printing finally remakes the printing user interface.
Switching printers at print dialog time, desktop printers that allow
users to move a print job from one printer to another, and much better
support for paper types are just three examples of making the printing
experience for the user much simplier, yet more powerful.

Another key benefit for users is that GX pictures don't have any of
the horrible 72-dpi problems that you run into with PICTs.  And Portable
Digital Documents extend this idea so that a user can create a PPD
and not wworry about not having the right font if they try to print
or view it on another system.

I could go on, but you get my drift.

__ Michael Peirce        __ [e-mail]
__ Peirce Software, Inc. __ 719 Hibiscus Place, Suite 301
__                       __ San Jose, California USA 95117-1844
__ Makers of: Smoothie & __ voice: +1.408.244.6554 fax: [phone]
__    Peirce Print Tools __ AppleLink: peirce & AOL: AFC Peirce

+++++++++++++++++++++++++++

>From [e-mail] (Brian Lowry)
Date: 30 May 1994 21:05:13 GMT
Organization: Dept. of Chemical Eng., University of Alberta

In article <[e-mail]>, [e-mail] (John Nagle)
wrote:

>       Well, we now have Quickdraw GX, which is a 2D object-oriented
> graphics system.  This is nice, but does it solve a real problem?

  Yes, by expressing coordinates as fixed point numbers instead of
integers.  That alone is enough to recommend it.

--

Brian Lowry

+++++++++++++++++++++++++++

>From [e-mail] (Gordon Apple)
Date: 30 May 1994 21:54:19 -0000
Organization: Los Angeles Macintosh Group BBS

> Yes, by expressing coordinates as fixed point numbers instead of
>integers.  That alone is enough to recommend it.


     I think it's ironic that Quickdraw GX went to such lengths (i.e.,
"Fixed" format) to avoid floating point operations, and is being released
almost simultaneously with the switch to PowerPC processors that run blazing
fast floating point that would have been faster than using "Fixed".

+++++++++++++++++++++++++++

>From [e-mail] (Tom Dowdy)
Date: Tue, 31 May 1994 17:06:52 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail]
(Michael Peirce) wrote:

>
> In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (John Nagle) writes:
> >       Well, we now have Quickdraw GX, which is a 2D object-oriented
> > graphics system.  This is nice, but does it solve a real problem?
> > It's not a full 3D system, so you can't use it for 3D graphics.
> > It's not compatible with existing object-oriented graphics standards,
> > like X or PHIGS.  It's complicated; several volume of manuals are required.
> > Rescalable icons are nice, but Quickdraw GX seems overkill just to
> > achieve that.  What kind of application would be simpler if written to use
> > Quickdraw GX?
>
> For me the two most important parts of QuickDraw GX aren't specific
> to it's graphics engine: Typography and Printing.

Michael mentions several nice things about these two areas, and
one nice thing about graphics (the no-72 dpi picture thingie).

I'd like to mention several other "nice graphics thingies" just
to give that part of GX even time.

 - rotation of all objects (everyone asks, so I call it out)

 - 3X3 transformation matricies (including perspective)

 - area, length, and other geometric information routines

 - full geometry engine, letting you hit test, subdivide, and
   intersect (via any boolean operator that makes sense) any two
   shapes and get a device-independant GEOMETRY out the other side.
   No other general purpose graphics system has this, and it lets you
   do some excellent things, such as creating shapes from other
   shapes in a drawing package.  (I personally think this area
   is very exciting, as I'd love to be able to SUBTRACT from
   one shape to create masks and such).

 - VERY powerful transfer mode functionality (and it all prints to
   everything, including PostScript).

 - device and space independant color, allowing you to create
   objects in any color space you feel comfortable with, and have
   the graphics system worry about the translation

 - curves

 - shape tagging, which lets you attach information or hints
   that are of use to either you or the system to shapes and pictures.
   (and also lets us extend GX in the future without the need to
   rev existing applications)

 - pictures can be "walked" or edited without the need to replay them
   to do so.

GX is lots of books.  But the API is really well thought out, and
once you start using it, you'll find that most API calls make sense
and you can figure them out by "guessing" the name.

ob funny: when the PrintShop first started working with the GX graphics
system, we liked to "make up" fake API calls by combining the logical
flow of the API into nonsense API calls that sounded useful:
 GXGetTransformViewPortMappingStyle()
 GXSetMappingInk()


--
 Tom Dowdy                  Internet: [e-mail]
 Apple Computer MS:302-3KS  UUCP: {sun,voder,amdahl,decwrl}!apple!dowdy
 1 Infinite Loop            AppleLink: DOWDY1
 Cupertino, CA 95014
 "The 'Ooh-Ah' Bird is so called because it lays square eggs."

+++++++++++++++++++++++++++

>From [e-mail] (Tom Dowdy)
Date: Tue, 31 May 1994 17:11:45 GMT
Organization: Apple Computer, Inc.

In article <2sbrv9$[e-mail]>, [e-mail] (David Opstad) wrote:

> In article <[e-mail]>, John Nagle <[e-mail]> wrote:
> >      Well, we now have Quickdraw GX, which is a 2D object-oriented
> >graphics system.  This is nice, but does it solve a real problem?
> >It's not a full 3D system, so you can't use it for 3D graphics.
> >It's not compatible with existing object-oriented graphics standards,
> >like X or PHIGS.  It's complicated; several volume of manuals are required.
> >Rescalable icons are nice, but Quickdraw GX seems overkill just to
> >achieve that.  What kind of application would be simpler if written to use
> >Quickdraw GX?
>
> A word processing or page layout app would be much simpler using GX, since the
> typographic expressiveness built into GX is very great.

One thing Dave didn't mention is that at the WWDC during the type
demo we showed a sample application using GX and its rich text to create
page layouts.  The application does multiple collumns, wraps text
around objects (using the cool GX geometry engine), and flows across
multiple pages.  It prints (and we've used to it to create some
cool party invites here!), saves, and can handle custom page setups
(doesn't yet do multiple formats).

Except for all of the "app stuff" like clipboard, typing,
cut and paste, undo, etc -- it's pretty much fully functional.

It's 50K of compiled code.  Something I think is quite impressive --
and the savings comes from thinking in a GX world where the system
handles more of the work for you.

--
 Tom Dowdy                  Internet: [e-mail]
 Apple Computer MS:302-3KS  UUCP: {sun,voder,amdahl,decwrl}!apple!dowdy
 1 Infinite Loop            AppleLink: DOWDY1
 Cupertino, CA 95014
 "The 'Ooh-Ah' Bird is so called because it lays square eggs."

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Tue, 31 May 1994 13:02:27 -0700
Organization: Internet for the Olympic Peninsula

In article <dowdy-310594095217@17.202.68.12>, [e-mail] (Tom Dowdy)
wrote:

> GX is lots of [Inside Macintosh} books.  But the API is really well thought
> out, and
> once you start using it, you'll find that most API calls make sense
> and you can figure them out by "guessing" the name.

Tom...I fully agree.  You and friends did very well.

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   [e-mail]

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Tue, 31 May 1994 22:00:32 GMT
Organization: Apple Computer

John Nagle, [e-mail] writes:
> What kind of application would be simpler if written to use
> Quickdraw GX?

Any kind of illustration program a la Illustrator or FreeHand or Canvas. GX
makes it very easy to write such programs, since it does so much work for
you: not only does it support powerful graphics primitives like quadric
Beziers, fancy options like dashes and joins, and really sophisticated color
models, but it also makes it very easy to manipulate these objects.
Hit-testing any GX objects (including type) is mostly just a matter of one
call.

Whether the big guns like Aldubeus or Deneba will move over to GX is unclear;
after all, they've already got code to do most of this stuff. But remember
how after 32-bit QuickDraw appeared we started to get some good color paint
programs from smaller developers that were cheap and reasonably powerful for
mere mortals? That's because 32BQD made it so much easier to do offscreen
color graphics. I think GX will have the same effect on illustration and
typography software, since it makes it possible to do very powerful
PostScript-style (and more!) graphics without requiring you to write your own
rendering engine for display or build custom PostScript code for printing.

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

+++++++++++++++++++++++++++

>From [e-mail]
Date: 31 May 94 15:53:49 MST
Organization: (none)

In article <dowdy-310594100526@17.202.68.12>, [e-mail] (Tom Dowdy) writes:
>
> One thing Dave didn't mention is that at the WWDC during the type
> demo we showed a sample application using GX and its rich text to create
> page layouts.  The application does multiple collumns, wraps text
> around objects (using the cool GX geometry engine), and flows across
> multiple pages.  It prints (and we've used to it to create some
> cool party invites here!), saves, and can handle custom page setups
> (doesn't yet do multiple formats).
>
> Except for all of the "app stuff" like clipboard, typing,
> cut and paste, undo, etc -- it's pretty much fully functional.
>
> It's 50K of compiled code.  Something I think is quite impressive --
> and the savings comes from thinking in a GX world where the system
> handles more of the work for you.
>

Is it available as sample source code or will it be?


Lawson

+++++++++++++++++++++++++++

>From [e-mail]
Date: 31 May 94 21:14:40 MST
Organization: (none)

In article <[e-mail]>, Jens Alfke <[e-mail]> writes:
> John Nagle, [e-mail] writes:
>> What kind of application would be simpler if written to use
>> Quickdraw GX?
>
[snip]

> Whether the big guns like Aldubeus or Deneba will move over to GX is unclear;
> after all, they've already got code to do most of this stuff. But remember
> how after 32-bit QuickDraw appeared we started to get some good color paint
> programs from smaller developers that were cheap and reasonably powerful for
> mere mortals? That's because 32BQD made it so much easier to do offscreen
> color graphics. I think GX will have the same effect on illustration and
> typography software, since it makes it possible to do very powerful
> PostScript-style (and more!) graphics without requiring you to write your own
> rendering engine for display or build custom PostScript code for printing.
>

I think that eventually even games will start making use of GX once it becomes
a standard on enough machines...

Will GX ship with 7.5 or later?



Lawson

+++++++++++++++++++++++++++

>From [e-mail] (Daniel R. Kegel)
Date: 1 Jun 1994 05:45:46 GMT
Organization: California Institute of Technology, Pasadena

[e-mail] writes:
>I think that eventually even games will start making use of GX once it becomes
>a standard on enough machines...
Roger on that one.

>Will GX ship with 7.5 or later?
I hear it will ship with 7.5, but my info is a couple months old.

-Dan

+++++++++++++++++++++++++++

>From [e-mail] (Peter F Davis)
Date: Wed, 1 Jun 1994 14:24:02 GMT
Organization: The World @ Software Tool & Die

[e-mail] (Tom Dowdy) writes:
    .
    .
    .

>I'd like to mention several other "nice graphics thingies" just
>to give that part of GX even time.
    .
    .
    .

> - curves

Actually, this is one of the things that really frustrates me about
GX.  Everyone else is using cubics.  Why did GX go with quadrics?

-pd
--
===============================================================================
                Peter Davis

         "Standardization is the opposite of innovation."

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Wed, 1 Jun 1994 21:30:07 GMT
Organization: Apple Computer

Peter F Davis, [e-mail] writes:
> Actually, this is one of the things that really frustrates me about
> GX.  Everyone else is using cubics.  Why did GX go with quadrics?

(1) Quadrics are a lot faster to render, and to perform other operations on
(like intersection.)

(2) Cubics are mathematically intractable under some geometric operations.
For example, insetting or outsetting a shape made of cubics would result in
curves of degree 6; whereas insetting or outsetting quadrics just results in
new quadrics. This kind of ability is absolutely fundamental to GX's geometry
engine, where you can apply any kind of geometric operation to a shape and
end up with another shape. Note that in PostScript you cannot do this, which
makes some kinds of operations insanely difficult or impossible. (I once
worked at a font company and we wanted to apply operations like insetting or
outsetting to character outlines. What we had to do to implement this in
PostScript would curl your hair, and it didn't even work that well. With GX
it would have been trivial.)

(3) In practice, for drawing, quadrics are nearly as powerful as cubics. Most
of the kinds of shapes people actually draw in illustration programs can be
rendered with only a few more quadrics than you'd need cubics for. It turns
out the kind of cubics that _are_ really difficult to approximate as quadrics
are the really twisty, loopy ones that people learn very quickly not to use
in drawing.

Disclaimer: I don't work on GX. Most of this is based on what I've learned
over the years or have been told by people on the GX team.

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 2 Jun 94 17:27:53 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (John Nagle) writes:
>       Well, we now have Quickdraw GX, which is a 2D object-oriented
> graphics system.  This is nice, but does it solve a real problem?

Absobloodylutely!

> It's not a full 3D system, so you can't use it for 3D graphics.
> It's not compatible with existing object-oriented graphics standards,
> like X or PHIGS.

I notice you didn't say "not compatible with existing _widespread_ object-
oriented graphics standards"...

>  It's complicated; several volume of manuals are required.

No it isn't! Add up all the volumes of QuickDraw and Printing Manager
documentation, including all the tech notes on printing hacks and the like.
Compare that to the size of the QuickDraw GX documentation. Now compare the
respective functionality you get. The GX API is a model of simplicity,
compared to all the accretions to QuickDraw that have accumulated over the
years.

> Rescalable icons are nice, but Quickdraw GX seems overkill just to
> achieve that.  What kind of application would be simpler if written to use
> Quickdraw GX?

ALL OF THEM!!! Other people have mentioned the typography and printing support.
Perhaps you aren't clear how much functionality GX gives you: In the
typography, you get much cleaner multilingual support than old QuickDraw is
capable of; contextual and alternate character forms; font variations
(what Adobe calls "multiple masters"); and automatic justification and kerning.

In the printing support, you get: anything you can draw, you can print! And
this applies to both PostScript and non-PostScript printers. You realize how
much of a breakthrough this is? All those times people have torn out their hair
over things coming out different on the printer compared to how they look on
the screen--all that goes away! And you get printer sharing and background
printing for *all* printers. And it is easier for third parties to develop
printer drivers. And it is easier still for other third parties to write
extensions that hook into the printing process in all kinds of useful ways
(such as Michael Peirce's "Peirce Print Tools").

And the graphics is pretty cool, too.

Look at it this way: when the original Macintosh came out in 1984, a lot of
people wondered why they would need the graphics and the text-graphics
integration, to do things that they were happily doing on typewriter-like
systems before. Nobody seriously asks that question any more. GX will similarly
raise people's expectations of what basic text and graphics handling is all
about.

The coming of the typewriter was a giant step backwards for the printed word,
and computers have only made things worse. The original Mac went a long way to
countering a lot of the pervasiveness of that "typewriter mentality". But with
QuickDraw GX, we can finally say that the computer is capable of enriching,
rather than retarding, the development of all that is best in typography, and
that the ghost of the typewriter has been well and truly laid to rest.
Long live type!

Lawrence D'Oliveiro                       fone: [phone]
Info & Tech Services Division              fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
A: OS/2 2.1, CD-i, and the Commodore Amiga.
Q: Name 3 products which have outsold Windows NT.

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 3 Jun 94 11:05:01 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (John Nagle) writes:

> [GX is] complicated; several volume of manuals are required.

Just to prove that GX is not only powerful for dealing with complex things,
it's also easy to use for simple things, here's a couple of minimal, _complete_
demo programs for you to compare. (I compiled and ran both versions with
THINK C 6, so I know they work.)

First, the QuickDraw version:

    #include <QuickDraw.h>

    void main(void)
      {
    GrafPort MyPort;

    InitGraf(&qd.thePort);
    OpenPort(&MyPort);
    MoveTo(100, 100);
    DrawString("\pHello, World!");
    ClosePort(&MyPort);
      } /*main*/

Next, the QuickDraw GX version:

    #include <math types.h>
    #include <math routines.h>
    #include <graphics routines.h>

    void main(void)
      {
    gxPoint where = {IntToFixed(100), IntToFixed(100)};
    #define TheText "Hello, World!"

    GXDrawText(sizeof(TheText), (unsigned char *) TheText, &where);
      } /*main*/

Now, what do you think of their relative complexity?

Lawrence D'Oliveiro                       fone: [phone]
Info & Tech Services Division              fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
Please do not feed the vegetables.

+++++++++++++++++++++++++++

>From [e-mail] (Michael Peirce)
Date: Fri, 3 Jun 94 16:09:15 PST
Organization: Peirce Software, Inc.


In article <2smvne$[e-mail]> (comp.sys.mac.programmer), [e-mail] (Jon Wdtte) writes:
> >3. No stupid conversions and typecasting to remember all over the place.
>
> Okay, I buy that.

Personally I blame that on C.  C just doesn't have a "native"
fixed type with associated operations.

Also (very minor point) I use the ff() macro rather than the
IntToFixed() - they are equivalent, but ff is more compact.

I do wish there was a VALIDATE mode that would yell when it
started seeing coordinates like 0x00000001 rather than
0x00010000.  Such tiny coordinates can't be common or generally
useful.

I have gotten into trouble by passing integer coordinates rather
than fixed coordinates, though they aren't hard bugs to figure
out.
____________

My only real grip with GX is that the interface is opague.  I
understand the rational that they might/will change things
inside at a later date.  That's well and good, but it makes it
MUCH harder to debug. With old QuickDraw I could root around in
the debugger and see exactly what my visRegion was set to and
such.  With GX there is no way to see, for example, what my Ink
happens to be or my clip shape or whatever.

They supply GraphicsBug, but it's basically useless for the kind
of work I do (non-applications).  And it's a pretty aweful
interface even for app use - it makes Jasik look like an UI
god. [ 1/2 :-) ]  And it crashes all the time for me.

What I'd like to see is a way to peer inside.  Make it 100%
clear that things will change and all that, but allow us to
debug things in a reasonable way!

__ Michael Peirce        __ [e-mail]
__ Peirce Software, Inc. __ 719 Hibiscus Place, Suite 301
__                       __ San Jose, California USA 95117-1844
__ Makers of: Smoothie & __ voice: +1.408.244.6554 fax: [phone]
__    Peirce Print Tools __ AppleLink: peirce & AOL: AFC Peirce

+++++++++++++++++++++++++++

>From Rick Wong <[e-mail]>
Date: 3 Jun 1994 23:06:32 GMT
Organization: Stanford University

In article <[e-mail]> ,
[e-mail] writes:
>Perhaps the sample source code to draw the same text a dozen times,
rotated by
>30 degrees each time in a loop?
>
>Takes only a few lines more than simply drawing the text in the first
place...
>
>
>Lawson


#include <math types.h>
#include <math routines.h>
#include <graphics routines.h>
#include <string.h>

#define TheText "GX Rules!"

void main(void)
{
    gxPoint myPoint = {ff(100), ff(100)};
    gxShape myTextShape = GXNewText(strlen(TheText), TheText, &myPoint);
    gxTransform myShapeTransform = GXGetShapeTransform(myTextShape);
    int i;
    for (i = 0; i < 12; ++i) {
        GXDrawShape(myTextShape);
        GXRotateTransform(myShapeTransform, ff(30), myPoint.x, myPoint.y);
    }
    GXDisposeShape(myTextShape);
}


Any sort of rotation operation (including bitmaps) is trivial with
QuickDraw GX.  This doesn't even nick the surface of its capabilities.

I am just starting to read the QD GX docs, and I must say that I am
quite impressed by the job Apple's done.  Not only is QD GX loaded
with great new features, the underlying model is indeed well thought
out, and the APIs are exemplary in their cleanness and consistency.
I'm going to enjoy forgetting everything I ever learned about PixMaps,
GDevices, cluts, etc.


Rick Wong

+++++++++++++++++++++++++++

>From [e-mail] (Sho Kuwamoto)
Date: 3 Jun 94 17:35:05 GMT
Organization: Purdue University Physics Department

[e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>    #include <math types.h>
>    #include <math routines.h>
>    #include <graphics routines.h>
>
>    void main(void)
>      {
>    gxPoint where = {IntToFixed(100), IntToFixed(100)};
>    #define TheText "Hello, World!"
>
>    GXDrawText(sizeof(TheText), (unsigned char *) TheText, &where);
>      } /*main*/

One thing I'd like to see is a way to specify fixed point
constants from within the mac C compilers.  What?  Did I
hear you cry, "nonstandard"?  Well, what about four byte
chars (e.g., 'APPL')?  How standard are they?

I imagine being able to type 100F to represent a fixed point
100 in much the same way that one types 100L to represent a
long int 100.  I realize it's grossly nonstandard, but
wouldn't it make GX so much easier?

-Sho
--
[e-mail] <<-- finger this account to find out what I'm
                            having for lunch!

<A HREF="http://physics.purdue.edu/~sho/homepage.html">Sho Kuwamoto</A>.

+++++++++++++++++++++++++++

>From [e-mail] (Brian L. Matthews)
Date: 4 Jun 1994 01:06:33 GMT
Organization: A World of Information at Your Fingertips

In article <[e-mail]>,
Sho Kuwamoto <[e-mail]> wrote:
|>    gxPoint where = {IntToFixed(100), IntToFixed(100)};
|
|One thing I'd like to see is a way to specify fixed point
|constants from within the mac C compilers.

Well, if you're willing to switch to C++, it would be fairly easy to
make some classes so you could just say:

    gxPoint where = { 100, 100 };

and the compiler (with the help of some classes you write) would do the
right thing.

One could also be clever and make it so:

    gxPoint where = { 10.53, 9.47 };

also does (usually) the right thing.  And all without modifying the language.

This would also fix problems with accidentally passing an int where Fixed
was expected.  With proper declarations, such a thing wouldn't be possible
(well, wouldn't be easy.  Anything's possible in C :-)).

Brian

+++++++++++++++++++++++++++

>From [e-mail] (John Nagle)
Date: Sat, 4 Jun 1994 06:02:23 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

[e-mail] (Sho Kuwamoto) writes:
>One thing I'd like to see is a way to specify fixed point
>constants from within the mac C compilers.  What?  Did I
>hear you cry, "nonstandard"?  Well, what about four byte
>chars (e.g., 'APPL')?  How standard are they?

      Actually, multicharacter constants are standard C and C++, although
they are a recent addition to the language.

>I imagine being able to type 100F to represent a fixed point
>100 in much the same way that one types 100L to represent a
>long int 100.  I realize it's grossly nonstandard, but
>wouldn't it make GX so much easier?

      Why build it into the language?  Just add the new type.

     class QDfixed {
    long fval;
     public:
    QDfixed(int intval) { fval = intval * int_scale_factor; }
    QDfixed(QDfixed fixedval) { fval = fixedval.fval; }
    QDfixed(int intval, int fractpart) { fval = intval * int_scale_factor
                    + fractpart; }
        ....
     }

You get the idea.
Of course, because the Mac interface is still defined in terms of C, not
C++, the standard headers won't support this properly, but that could be
fixed with some glue routines expressed as inlines.

                    John Nagle

+++++++++++++++++++++++++++

>From [e-mail] (Mark Eaton)
Date: 4 Jun 1994 18:06:09 GMT
Organization: InfiNet

Ralph Martin ([e-mail]) wrote:
: In article <[e-mail]> Lawrence D'Oliveiro,
: [e-mail] writes:
: >Next, the QuickDraw GX version:
: >
: >    #include <math types.h>
: >    #include <math routines.h>
: >    #include <graphics routines.h>
: >
: >    void main(void)
: >      {
: >    gxPoint where = {IntToFixed(100), IntToFixed(100)};
: >    #define TheText "Hello, World!"
: >
: >    GXDrawText(sizeof(TheText), (unsigned char *) TheText, &where);
: >      } /*main*/
: >
: >Now, what do you think of their relative complexity?

: It's not obvious:

: Good points for Quickdraw:
: 1. Less headers.

I wonder if compiler providers like Symantec and MetroWerks will come up
with a unified header for GX that includes the necessary headers... Its just
a matter of time.

: 2. Functionality divided into smaller chunks (what to draw, where to draw
: separate).

Yes, but now we arent restricted to one 'pen'. We can have any number of
points without having to call move and moveto constantly. I think the new
way is better.

: 3. No stupid conversions and typecasting to remember all over the place.

: Good points for Quickdraw GX:
: 4. No rubbish concerning initialising and setting up ports.

: Overall - the Quickdraw is easier to read, and looks more maintainable
: and less error prone because of point 3. It is probably easier to write
: given point 2, as the programmer has to concentrate on less things at
: once.

Had he used unsigned char* theText = "Hello World"; he wouldnt have needed a
cast. He used a numdefine instead... It was a programmer choice...

: Seriously, you are probably right about QuickDraw GX having a better
: model underlying it. I'm not so sure that the realisation of that model
: into an API is a great leap forward though. Perhaps longer examples would
: be more convincing!

: Ralph

--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Mark Eaton          | MacXPerts - Custom Mac and Newton Software
[e-mail]      | 3228L W. Cary St.
                    | Richmond, VA. 23221
            | [phone]     FAX: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Mark Eaton)
Date: 4 Jun 1994 18:11:20 GMT
Organization: InfiNet

Rick Wong ([e-mail]) wrote:
: #define TheText "GX Rules!"

: void main(void)
: {
:     gxPoint myPoint = {ff(100), ff(100)};
:     gxShape myTextShape = GXNewText(strlen(TheText), TheText, &myPoint);

Its interesting that GX uses shapes and converts text to shapes. This is
very much like the Newton form of QuickDraw. Did some of the engineers work
on both, or is this just coincidence?

:     gxTransform myShapeTransform = GXGetShapeTransform(myTextShape);
:     int i;
:     for (i = 0; i < 12; ++i) {
:         GXDrawShape(myTextShape);
:         GXRotateTransform(myShapeTransform, ff(30), myPoint.x, myPoint.y);
:     }
:     GXDisposeShape(myTextShape);
: }


: Any sort of rotation operation (including bitmaps) is trivial with
: QuickDraw GX.  This doesn't even nick the surface of its capabilities.

: I am just starting to read the QD GX docs, and I must say that I am
: quite impressed by the job Apple's done.  Not only is QD GX loaded
: with great new features, the underlying model is indeed well thought
: out, and the APIs are exemplary in their cleanness and consistency.
: I'm going to enjoy forgetting everything I ever learned about PixMaps,
: GDevices, cluts, etc.

Much agreed!

: Rick Wong

--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Mark Eaton          | MacXPerts - Custom Mac and Newton Software
[e-mail]      | 3228L W. Cary St.
                    | Richmond, VA. 23221
            | [phone]     FAX: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 7 Jun 94 11:41:28 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <2sqfqh$[e-mail]>, [e-mail] (Mark Eaton) writes:
>
> Had he used unsigned char* theText = "Hello World"; he wouldnt have needed a
> cast. He used a numdefine instead... It was a programmer choice...

Actually, it was my ignorance of C showing. :-}

Seriously, though, if unsigned char* theText = "Hello World" compiles without
needing a cast, while I needed a cast to pass the exact same literal to an
unsigned char* argument, isn't that an inconsisten-C?

Lawrence D'Oliveiro                       fone: [phone]
Info & Tech Services Division              fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 7 Jun 94 11:46:51 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Michael Peirce) writes:
>
> Also (very minor point) I use the ff() macro rather than the
> IntToFixed() - they are equivalent, but ff is more compact.

I deliberately used IntToFixed to try to make it clearer what was going on.

> What I'd like to see is a way to peer inside.  Make it 100%
> clear that things will change and all that, but allow us to
> debug things in a reasonable way!

There are some GX functions that provide such an escape, eg GXGetShapeStructure.
If you have a look at the source of SlideMaster that came with the beta 1
distribution, you can see an example of this in use (it makes a big difference
to the speed of the "Particles" animation!).

All you need is some documentation on how to use this, or, failing that, some
time spent poking around for yourself...

Lawrence D'Oliveiro                       fone: [phone]
Info & Tech Services Division              fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 7 Jun 94 12:02:22 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, Ralph Martin <[e-mail]> writes:
> In article <[e-mail]> Lawrence D'Oliveiro,
> [e-mail] writes:
>>
>>Now, what do you think of their relative complexity?
>
> Good points for Quickdraw:
> 2. Functionality divided into smaller chunks (what to draw, where to draw
> separate).

Actually, this statement is more true of GX in general. My sample code was for
drawing text: consider equivalent code for drawing, say, polygons. (Do you want
me to inflict some on you?)

> 3. No stupid conversions and typecasting to remember all over the place.

I was using THINK C for communication purposes. Normally I use Modula-2.
Much less typecasting. :-)

Lawrence D'Oliveiro                       fone: [phone]
Info & Tech Services Division              fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 7 Jun 94 12:04:03 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <2smvne$[e-mail]>, [e-mail] (Jon Wdtte) writes:
> In <[e-mail]> Ralph Martin <[e-mail]> writes:
>
>>Good points for Quickdraw GX:
>>4. No rubbish concerning initialising and setting up ports.
>
> Actually, there is; Lawrence was cheating (or rather not using
> a relevant test case)

I wasn't cheating. The GX documentation says you can leave out all the client
setup if the defaults are adequate, and in this case, they were!

Lawrence D'Oliveiro                       fone: [phone]
Info & Tech Services Division              fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00

+++++++++++++++++++++++++++

>From [e-mail] (Zalman Stern)
Date: Tue, 7 Jun 1994 01:21:35 GMT
Organization: Adobe Systems Incorporated

Lawrence D'Oliveiro, Waikato University writes
> Seriously, though, if unsigned char* theText = "Hello World" compiles
without
> needing a cast, while I needed a cast to pass the exact same literal to an
> unsigned char* argument, isn't that an inconsisten-C?

Its not an inconsistency because it doesn't compile.
--
Zalman Stern           [e-mail]            [phone]
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
   Never let a "final candidate" subscript get above the age of consent.

+++++++++++++++++++++++++++

>From [e-mail] (Michael Peirce)
Date: Mon, 6 Jun 94 20:25:05 PST
Organization: Peirce Software, Inc.


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
> In article <[e-mail]>, [e-mail] (Michael Peirce) writes:
> >
> > Also (very minor point) I use the ff() macro rather than the
> > IntToFixed() - they are equivalent, but ff is more compact.
>
> I deliberately used IntToFixed to try to make it clearer what was going on.
>
> > What I'd like to see is a way to peer inside.  Make it 100%
> > clear that things will change and all that, but allow us to
> > debug things in a reasonable way!
>
> There are some GX functions that provide such an escape, eg GXGetShapeStructure.

GXGetShapeStructure will return geometry information about a shape.
Other calls can also return infomation about other stuff like inks
and transforms.

With these it is possible to build some sort of debugging library
yourself, but it really doesn't help much when you are stepping through
source code and need to see what the ink of a given shape is or maybe
its transform.

GraphicsBug tries to address some of this, but it was clearly written
by someone that thinks Macsbug was a great model to follow for a debugger
UI :-(  It's completely unusable by folks who don't have a friendly event
loop handly.  People who write print drivers or extensions or even App
code that uses GX for just a little work, then cleans up before idle
time are left in a lurch.  I had to dust off some really old code
that spits out debugging information over the net to a log app so I can
get some idea what's going on deep in the bowels of message overrides.
This is code that I haven't had to use since symbolic debugging arrived
on the Mac many moons ago.

Maybe I'm carrying on at a bit too much length, but having spend the
last months debugging our printing extensions and I've wasted large
amounts of time because its hard to debug GX code.  (You also have
to jump through hoops to get source debugging to work with print drivers
and extensions, but that's yet another story!).

The easier it is to debug GX apps and such, the sooner they will start
showing up.

__ Michael Peirce        __ [e-mail]
__ Peirce Software, Inc. __ 719 Hibiscus Place, Suite 301
__                       __ San Jose, California USA 95117-1844
__ Makers of: Smoothie & __ voice: +1.408.244.6554 fax: [phone]
__    Peirce Print Tools __ AppleLink: peirce & AOL: AFC Peirce

+++++++++++++++++++++++++++

>From [e-mail] (Matt Mora)
Date: 7 Jun 1994 13:33:06 -0700
Organization: SRI International, Menlo Park, CA

In article <[e-mail]> [e-mail] (Michael Peirce) writes:

>GraphicsBug tries to address some of this, but it was clearly written
>by someone that thinks Macsbug was a great model to follow for a debugger
>UI :-(  It's completely unusable by folks who don't have a friendly event
>loop handly.  People who write print drivers or extensions or even App


I thought that the GX team answered your question about that. Didn't
they mention that there is a call you can use to simulate a Event
loop?


Xavier





--
___________________________________________________________
Matthew Xavier Mora                       [e-mail]
SRI International                       [e-mail]
333 Ravenswood Ave                    Menlo Park, CA. 94025

+++++++++++++++++++++++++++

>From [e-mail] (Michael Peirce)
Date: Tue, 7 Jun 94 15:06:31 PST
Organization: Peirce Software, Inc.


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] writes:
> Will GX ship with 7.5 or later?

QuickDraw GX swill ship with 7.5.  Before then, GX can be licensed
by third party companies that want to include it with their products.

Since our Peirce Print Tools won't work without GX, we are in the
process of licensing GX and will bundle it in with our product
in a week (or two or three depending on how long it takes Apple licensing
to process the paperwork!).  It's four HDFD disks and will work with
System 7.1 or later.

__ Michael Peirce        __ [e-mail]
__ Peirce Software, Inc. __ 719 Hibiscus Place, Suite 301
__                       __ San Jose, California USA 95117-1844
__ Makers of: Smoothie & __ voice: +1.408.244.6554 fax: [phone]
__    Peirce Print Tools __ AppleLink: peirce & AOL: AFC Peirce

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 9 Jun 94 11:39:00 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Michael Peirce) writes:
>
> In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>> In article <[e-mail]>, [e-mail] (Michael Peirce) writes:
>>
>> > What I'd like to see is a way to peer inside.  Make it 100%
>> > clear that things will change and all that, but allow us to
>> > debug things in a reasonable way!
>>
>> There are some GX functions that provide such an escape, eg GXGetShapeStructure.
>
> GXGetShapeStructure will return geometry information about a shape.
> Other calls can also return infomation about other stuff like inks
> and transforms.
>
> With these it is possible to build some sort of debugging library
> yourself, but it really doesn't help much when you are stepping through
> source code and need to see what the ink of a given shape is or maybe
> its transform.

You could write a MacsBug dcmd or two to make these calls. Since GX is
supposed to be interrupt-reentrant, they might even work quite safely.

> GraphicsBug [is] completely unusable by folks who don't have a friendly event
> loop handly.  People who write print drivers or extensions or even App
> code that uses GX for just a little work, then cleans up before idle
> time are left in a lurch.

Here's the tip that was given out at the GX in QD apps and debugging tips
session at WWDC: break into MacsBug, switch to the system heap zone, then type
"g InitEventLoop" (I think that's how it's spelt). This is supposed to get you
into a dummy event loop so you can use GraphicsBug on your driver/extension.

By the way, I think this only works with the debugging version of GX. MacsBug
can't seem to find a symbol resembling this in the 1.0f2c13 (non-debugging)
version I'm running.

Lawrence D'Oliveiro                       fone: [phone]
Info & Tech Services Division              fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00

+++++++++++++++++++++++++++

>From [e-mail] (Michael Peirce)
Date: Wed, 8 Jun 94 21:52:09 PST
Organization: Peirce Software, Inc.


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>
> Here's the tip that was given out at the GX in QD apps and debugging tips
> session at WWDC: break into MacsBug, switch to the system heap zone, then type
> "g InitEventLoop" (I think that's how it's spelt). This is supposed to get you
> into a dummy event loop so you can use GraphicsBug on your driver/extension.
>
> By the way, I think this only works with the debugging version of GX. MacsBug
> can't seem to find a symbol resembling this in the 1.0f2c13 (non-debugging)
> version I'm running.

Right, but who uses Macsbug?  Seriously. I guess the GX team does.

Yikes!

__ Michael Peirce        __ [e-mail]
__ Peirce Software, Inc. __ 719 Hibiscus Place, Suite 301
__                       __ San Jose, California USA 95117-1844
__ Makers of: Smoothie & __ voice: +1.408.244.6554 fax: [phone]
__    Peirce Print Tools __ AppleLink: peirce & AOL: AFC Peirce

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Mon, 13 Jun 1994 09:56:34 +0800
Organization: Department of Computer Science, The University of Western Australia

In article <[e-mail]>, Ralph Martin
<[e-mail]> wrote:

>Seriously, you are probably right about QuickDraw GX having a better
>model underlying it. I'm not so sure that the realisation of that model
>into an API is a great leap forward though. Perhaps longer examples would
>be more convincing!

The important point is not whether GX is simpler, it's that you can do
more.  Colour QuickDraw is fine until you hit one of its boundaries and
then you suffer much pain and misery trying to work around it.  With GX
the boundaries are much further out, thus you're less likely to hit them.
The classic example here is rotated text.

Hmm, of course when you do hit GX's boundaries...
--
Quinn "The Eskimo!"      <[e-mail]>     "Support HAVOC!"
Department of Computer Science, The University of Western Australia
  Who, as a Mac user as well as a programmer, can't wait for GX drawing/DTP.
  And is glad he doesn't have to write it (:

---------------------------

>From [e-mail] (Tyson B. Boucher)
Subject: [Q] Programming the AT&T 3210?
Date: Thu, 09 Jun 1994 03:15:16 -0800
Organization: Teleport - Portland's Public Access [phone]

    Does anyone know of a cheap/free way to learn how to program the 3210
(the DSP in av Macs)?  IUd like to take advantage of it, but IUm still
working on getting a full set of IM, so I donUt want to spend a lot buying
a manual from AT&T if I can help it.  Besides, this is (for now) just a
casual interest and I donUt want to toss a lot of $$$ after this if it
turns out to be not worth it.

--
|          [e-mail]           |
|                   /-Student              |
|  Tyson B. Boucher-|-Programmer           |
|                   \-lifeless.net.bum  ;) |

+++++++++++++++++++++++++++

>From Darrin Cardani <[e-mail]>
Date: Fri, 10 Jun 1994 13:55:13 GMT
Organization: AT&T Global Information Solutions, Atlanta

>In article <[e-mail]> Tyson B. Boucher writes:
>    Does anyone know of a cheap/free way to learn how to program the 3210
>(the DSP in av Macs)?  IUd like to take advantage of it, but IUm still
>working on getting a full set of IM, so I donUt want to spend a lot buying
>a manual from AT&T if I can help it.  Besides, this is (for now) just a
>casual interest and I donUt want to toss a lot of $$$ after this if it
>turns out to be not worth it.

First off, most readers don't recognize the funky characters you've got in
your post. You might want to use standard ascii when posting.

But to answer your question, The manual for the language is free from AT&T.
I don't have the address with me right now.

The commercially available development system is $1000. Some people on the
net are trying to write one that I assume will be ftp'able from the major mac
archive sites. There is a group called comp.dsp. You might want to check it
out and ask for the Mac DSP mini-faq. It has more info. (like the phone number
for the free manual.)

Darrin







+++++++++++++++++++++++++++

>From [e-mail] (Thomas PUSHPATHADAM)
Date: 11 Jun 1994 21:19:10 GMT
Organization: SOCS, McGill University, Montreal, Canada

(*** Note:  posting from borrowed account ***)

> Does anyone know of a cheap/free way to learn how to program the 3210
> (the DSP in av Macs)?  IUd like to take advantage of it, but IUm
> still
> working on getting a full set of IM, so I donUt want to spend a lot
> buying
> a manual from AT&T if I can help it.  Besides, this is (for now) just
> a casual interest and I donUt want to toss a lot of $$$ after this if
> it turns out to be not worth it.

Stefan Arentz ([e-mail]), Andrew Grignon
([e-mail]) and myself (Paul Lalonde,
[e-mail]) are currently writing an assembler for the
DSP3210.  Since we're doing this in our scarce spare time, it's moving
rather slowly.  We want to upload to the major ftp sites by the end of
June.

In the meantime, you might call AT&T and ask for the "DSP3210
information manual".  It's free, and it introduces you to the DSP's
instruction set.  Their number is 1-800-372-2447.

You will also need the "Centris  660AV & Quadra 840AV developer note",
available on more recent Bookmark & developer CDs.  This documents the
interface to the DSP.

Hope this helps,

Paul Lalonde
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Amanda Walker)
Date: Mon, 13 Jun 1994 14:32:50 -0500
Organization: InterCon Systems Corporation, Herndon, VA  USA

Darrin Cardani <[e-mail]> writes:
> The commercially available development system is $1000.

Spectral Innovations is now selling the ARTA development for $495 without
support ($995 includes support).  I wouldn't advise doing this unless you've
done DSP code before, though :)...


Amanda Walker
InterCon Systems Corporation



---------------------------

End of C.S.M.P. Digest
**********************